Google Summer of Code for Mentors
/* This is process proposal */
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 in quota 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
- Popularity contest (options)
- a) After that all other mentors must review ALL marked proposals and assign with "popularity" score, which should be -1,0,+1
- b) 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.
- c) Mentors review 1 project of their choice and X randomly selected projects (score 4..-4)
- d) I was trying to get rid of notion that projects with the most mentors takes all the slots. Maybe for all other mentors average should be counted not the sum? This way mentor would be encouraged to rate other proposals and not afraid that this action would cause his loose his students. Since software does not support it directly we have to remove all the score that other mentors give at the final stage and replace with "average"
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.