Difference between revisions of "GSOCSelectionProcess"

From Nsnam
Jump to: navigation, search
(Created page with "= ns-3 Google Summer of Code Selection Process = This page describes how the ns-3 organisation reviews student applications for the Google Summer of Code programme and narrow...")
 
Line 45: Line 45:
  
 
== What are we looking for in a good proposal? ==
 
== What are we looking for in a good proposal? ==
 +
 +
Our objective is to select students who are potential future maintainers of the ns-3 project. Over the summer, the community will be investing time and effort in mentoring the students to achieve this end. That said, this is what a good proposal will look like:
  
 
# A detailed proposal that sets a realistic list of deliverables, demonstrates a clear path towards achieving the same, is complete, and technically sound.
 
# A detailed proposal that sets a realistic list of deliverables, demonstrates a clear path towards achieving the same, is complete, and technically sound.
Line 61: Line 63:
 
# Poor professional conduct in developing the application (extensive copy-pasting for instance).
 
# Poor professional conduct in developing the application (extensive copy-pasting for instance).
 
# There is little evidence for the candidate's technical abilities.
 
# There is little evidence for the candidate's technical abilities.
 +
# Very little mailing list and community engagement in developing the proposal.
 
# The candidate has other commitments for the summer (vacations, exams, coursework, another job etc.).
 
# The candidate has other commitments for the summer (vacations, exams, coursework, another job etc.).
 
# Previous failures within GSOC.
 
# Previous failures within GSOC.

Revision as of 13:03, 14 April 2013

ns-3 Google Summer of Code Selection Process

This page describes how the ns-3 organisation reviews student applications for the Google Summer of Code programme and narrows down on the final selections.



Selection Committee

The selection committee comprises all mentors for the respective year along with a set of community members (typically maintainers). If you would like to serve on the selection committee, please contact the organisation admin (Lalith).


Review Committee Checklist

  1. Sign up on Melange [1] as a mentor, and pick the ns-3 organisation(the organisation name is "The ns-3 network simulator"). You won't beable to see the applications otherwise.
  2. If you are the concerned mentor for a particular application, please select "Wish to mentor" on the left bar for the application so that we can assign you the application.
  1. Review *every* application and assign a score to each one. Pleasesee below for the scoring guidelines.
  2. After you've reviewed all applications, leave behind a *private*comment on your top 3 proposal picks, indicating your reasons fordoing so.
  3. If you're trying to leave a review for other reviewers to see, please make sure *you don't* leave a public comment.

[1] http://www.google-melange.com/gsoc/homepage/google/gsoc2013


Scoring System

On Melange, every reviewer should assign a score to every application. The scoring system is as follows

  • 1  : Spam application. **For mentors of the respective projects and admins ONLY**
  • 2  : Ignore proposal. **For mentors of the respective projects and admins ONLY**
  • 3  : One of the worst proposals, other reviewers should ignore it
  • 4  : This definitely doesn't deserve to get into GSoC
  • 5  : I'd rather this didn't get a slot
  • 6* : Don't care one way or the other whether it's funded
  • 7  : Mild enthusiasm. Fairly cool but niche, or average proposal
  • 8  : Student seems quite good, and the project is well thought out
  • 9  : This is one of my favourites
  • 10 : Highly recommended. **For mentors of the respective projects and admins ONLY**
  • 11 : Strongly recommended. **For mentors of the respective projects and admins ONLY***

6 should be your default score


What are we looking for in a good proposal?

Our objective is to select students who are potential future maintainers of the ns-3 project. Over the summer, the community will be investing time and effort in mentoring the students to achieve this end. That said, this is what a good proposal will look like:

  1. A detailed proposal that sets a realistic list of deliverables, demonstrates a clear path towards achieving the same, is complete, and technically sound.
  2. The proposal is an original document authored by the candidate, and is not a copy paste job.
  3. The proposal is scoped such that it has a strong chance of being successfully completed and merged by the end of the coding period.
  4. The candidate is technically very strong. This is judged through prior experience with contributing to ns-3 and/or other open-source projects, code samples, their past experience and through interviews conducted during the review process by the mentoring team.
  5. The candidate does not have any other commitments over the summer, and can devote 40 hours per-week as is required of GSOC candidates.
  6. The proposal has been discussed at length on the mailing list and/or IRC.
  7. The student is very likely to continue his/her involvement with the project after GSOC ends.


Signs of a bad proposal

  1. The proposal is a regurgitation of the project description and the recommended reading.
  2. Poor professional conduct in developing the application (extensive copy-pasting for instance).
  3. There is little evidence for the candidate's technical abilities.
  4. Very little mailing list and community engagement in developing the proposal.
  5. The candidate has other commitments for the summer (vacations, exams, coursework, another job etc.).
  6. Previous failures within GSOC.


Review Process

Pre-evaluation phase

The organisation admin makes a pass through all the proposals. The admin will assign a score of 1 to spam, very weak applications, and applications that are copy-paste jobs. These applications will not be considered for further review.


Timeframe: May 3rd to May 4th, 2013.


First review phase

  1. All members of the selection committee will assign scores to the applications based on the scoring system mentioned above. Note, the scores of 1, 2, 11, and 12 are reserved for the admins and the mentors of the corresponding projects.
  2. All reviewers must post a private comment for each of their top 3 proposal picks explaining their score. They are free to post comments for other applications as well.

At the end of the first review phase, admins will make a pass through the applications to ensure that scores are assigned equally across all proposals. This is for cases where some mentors are more lenient with awarding scores than others, and also to avoid situations of vested interests. Admins will adjust scores accordingly to balance against such situations.

Timeframe: May 4th to May 12th, 2013.


Second review phase

Admins will present a list of second round candidates for discussion by the committee. The committee will organise interviews with the candidates to probe for technical skill and to clarify aspects of the proposal.

Timeframe: May 12th to May 20th, 2013.


Final phase

Outcome of second review phase is discussed, and the final ranking list of candidates is decided.

Timeframe: May 20th to May 23rd, 2013.