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.

2020

• Do not accept a student if they had 0 interractions with the community before or during the application phase, even if their application looks good. In many situations, that type of students have communication and/or dedication issues that will end up sabotaging the project. We need to make sure, during the application phase (or even before that) that the student is interractive and prooves to posess the required communication and technical skills. They need to introduce themselves, produce some initial PRs and be active on the community (asking questions, interracting with mentors and other students, etc.).
  • Accepting students and then failing them at the first evaluation is a waste of everyone's time and resources. We need to avoid that as much as possible.
• Try out pre-acceptance tasks/exercises, specific to each project, that a student must first complete before we consider them eligible for being accepted.
  • Details https://forum.xwiki.org/t/proposal-for-google-summer-of-code-student-selection-process/7601
• The Community Bonding period is really important. We should do all we can to make the students understand that and have them actively learn, ask questions and get noticed in the community. If they don't perform during the Community Bonding period (except maybe for justified causes like school work/exams), we should not hesitate in failing them. Experience shows that inactive students during this period are extremely unlikely to adapt and adjust during the coding period. They will not integrate with the community and the project (which is the whole point of GSoC), even if they would manage to deliver a partially working project implementation.
  • Special note on projects building integrations with XWiki, where the student would know better the external system/platform but would not invest enough in learning XWiki early on. Past experiece shows that the student will struggle during the coding phase, when they reach XWiki topics and find themselves out of time/energy/resourcefulness to clarify them in time and also implement them. These clarifications should have been done during the Community Bonding period.

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.