[Soc-coordination] Ranking of the proposals ?

Erich Schubert erich at debian.org
Wed Apr 2 16:18:19 UTC 2008


Hi,
> Since the proposals can not be modified after the deadline, I would like
> to know what will be the criteria for Debian ?

Are you sure about that? The Timeline says:

Interim Period: Mentoring organizations review and rank student
proposals; where necessary, mentoring organizations may request further
proposal detail from the student applicant.

"requesting further proposal details" is to me a modification of the
proposal. The last years, at least the comment functionality was still
open.

We never had a set criteria list for Debian in any of the previous
years. The reviewers rank applications with the Google tool according to
their own criteria, and at the end we ensure things such as picking the
best application for a single topic only.
We never had to write down explicit rules, we always arrived at some
sort of agreement over the final project ranking.

Criterias probably are (in decreasing importance):
- strongly Debian related, doesn't fit other organizations better
- code project, documentation projects are ineligible
- well-written proposal  <-- essential
- suiteable mentor available (but we never had problems with that)
- no better proposal by a different student for the same idea (mostly a
mentors choice thing which one he considers 'best')
- importance for the project (rarely ever taken into account)

the most differentiation happens at the quality of the proposal. If a
student ends up convincing all mentors that proof-read the application
he'll get a high score in the Google tool.
We've largely removed projects that fail at the first two, and we've
asking many students for more details on their proposals already.

A well-written proposal should
- contain a timeline estimation, IMHO at a week-level if appropriate
- list relevant previous knowledge by the student
- give strong additional ideas beyond what was on the Wiki
- list relevant related software and projects, their strengths and
weaknesses, where the student wants to follow them and where to do
things differently

For example, a MergeMaster port application that doesn't mention debconf
and UCF isn't very well-written IMHO. Any student proposing to work here
needs to show that he's aware of the 3-way-diff and -merging
functionality already present in UCF (and why we still want MergeMaster)

best regards,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
      To be trusted is a greater complement than to be loved.       //\
              Der Wissende weiß, dass er glauben muß.               V_/_




More information about the Soc-coordination mailing list