We are listing here things we`ve learned while participating at Google Summer of Code. This page is meant to be useful for the years to come.

2019

  • Focus more on the evaluations:
    • Help the student wrap things up for each evaluation, specially the final one, that includes a report and release of working code.
    • Make sure no project finishes without a proper and working release of the work done so far.
    • Try more to avoid situations where students push work after the coding deadline has finished and when the evaluation period is ongoing. I.e. reminder that the student should be evaluated for the work done until then, excluding the actual evaluation period which is reserved for mentors to evaluate.
    • Try not to leave student evaluations for the last moment. We need to avoid situations where there are less than 2 days left for the deadline and mentors have not yet submitted the evaluation for their students.
  • Make sure all students follow the guidelines for reporting progress, where to store their code repository, where to put their final report, etc. We're aiming for a consistent approach and it's very easy for students to stray and get wild ideas or come up with approaches that are more convenient for them, individually. The mentors should notice this, answer when students ask and correct if students don't follow it.

2012

  • When XWiki is selected, send an announcement mail with a call-to-participation subject that people could forward to their friends.
  • Write a blog post on xwiki.org (even if you have one in xwiki.com)
  • Keep up the policy documents, they're really precious and show that XWiki is an organization that has some maturity in monitoring GSoC participatns
    • The current student guide is targeting accepted students.
    • Add a section for students that are applying. Mention the things we want from them (communication, etc).
  • Rules for grading student applications (1-5 ratings):
    • 1 star means spam, completely off topic
    • 2 stars means it's on topic (applying for an XWiki project), but very low quality
    • 3-5 stars for grading real proposals, where 5 stars means definitely +1, the student has a good proposal, exchanged some emails on the devs list, has some code written
  • Provide more detailed descriptions for projects and update them once students ask questions on the mailing list. This way we avoid answering to the same questions and we reuse as much as possible the replies from the list.
    • Another (more sloppy but more practical) option is to just add links to markmail thread in the project description so that interested students can easily identify the discussions where the project was mentioned and detailed
  • Make sure to pair proposals with mentors and secondary mentors before the student application period begins. All proposals that have not done so will not be considered.

2011

  • Require code samples from students.
Tags:
Created by Eduard Moraru on 2012/04/09 15:42
   

Get Connected