Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Google Summer of Code for Mentors

Revision as of 15:47, 21 April 2010 by Wim.jongman.remainsoftware.com (Talk | contribs) (Proposals Review Process)

/* This is process proposal */

Mentor Activities

As a mentor for eclipse foundation you will be involved in the following activities:

  • Review and Rank students proposals for all proposals submitted to eclipse foundation
  • Contacting students you want to mentor to obtain more information or giving them assignments
  • If proposal of your student is selected, mentoring the student and submitting evaluation reports

Proposals Review Process

Stage 1: Before proposals freeze deadline

  • Mentor can review proposals and ask student questions on the proposals or via e-mail
  • Mentor can ask student to change proposal if it incomplete
  • No scoring of the proposals at that time
  • Mentor can mark proposals as "willing to mentor"

Stage 2: Between proposals freeze and google initial allocations

  • Mentor can review proposals and ask student questions or give them assignments
  • Mentor should mark proposals as "willing to mentor" for these that he is willing to mentor
  • If there is no mentors for the project that student selected admin should probably ping the project to get mentor registered
  • Mentor should 'score' bad proposals (aka spam) with negative score
  • At the end of the stage admin should mark all negative proposal as ineligible
  • At the end of the stage admin should assign mentors to proposals that have suggested mentor
  • No 'positive' scoring of the proposals at that time yet

Stage 3: Between initial allocation and ranking freeze

  • No more asking students questions and changing proposal, proposal should text should be frozen
  • Based on number of eligible proposals per project (eclipse project) admin should come up with "quota" per project, which can be number with fractions (such as 1.5), the total sum of quotas should give us X which is number of allocated slots. Quota of 1.5 means that project will get 0 to 2 students (2 is maximum), and likely at least 1.
  • One person (usually assigned mentor) should mark top Y proposals for the project where Y is the max number of students and assign score up to 10 for each proposal. Each proposal per project should have unique score (i.e. 10, 9, 8, 3). Other proposals should not have any score, so other mentor can concentrate on high runners
  • After that all other mentors can dig in and assign proposals with "popularity" score, which should be -1,0,+1
How about: all other mentors must vote X projects with (X, X-1,,1) points and must score every unique number. 
So if there are 10 slots a mentor must score 10 proposals with 10,9,8,, or 1 point. 

Stage 4: Ranking freeze to final selection

  • Only admin can adjust proposal ranking based on initial score, popularity and assigned project quotas.
  • Depends on de-duplication results or project having more slots that initially allocation student not from top X can get a spot. So next student with highest score would get it.

Back to the top