Development:GSOC mentoring

Note: This article is a work in progress. Please feel free to edit it and add further notes/comments/suggestions.

Additional suggestions

From David Horat and Anthony Borrow:

Mentors

• All primary mentors should be regular core developers.

Selection process

• Create our own questionnaire
  1. Remark how important is to have time to develop a full time job as the SoC
  2. Remark how important is to have willpower to develop a work from home or try to search other places to work
  3. Remark how important is to do the job after accepting it and not wasting a slot that another student could have used
  4. Remark how good is for the student being successful in the GSoC (money, visibility, good for CV, recommendation letters, etc.)
  5. Remark how important is to collaborate and interact in the forums with the community even before choosing a project

• Test the student to see if he has got the necessary skills (PHP exercises, submitting a patch to an existing issue in the tracker, some kind of Moodle contest, etc.)
  1. Forums - Ability to communicate clearly and effectively on Moodle.org forums
  2. Tracker - Ability to create a tracker issues and effectively use the tracker as a means of communication
  3. Coding - Ability to create and use diff files demonstrated by creating a patch for an existing issue

• Projects should be limited to Moodle code and specific enough at the beginning to produce a workable timeline and list of subtasks
  1. For example, projects such as researching usability issues can be more narrowly defined as identify top 5 usability issues and produce patches to resolve based on community feedback
  2. Should projects like the IDE Project really be considered a Moodle project?

Controlling

• Check students public activity (forum posts, tracker comments, code updates, etc.)
• Updates:
  1. Keep using the Wiki pages as the main projects documentation, which must be up-to-date
  2. Force the student to blog publicly each day/2 days about his progress and in what he has spent his time working
  3. Use a Jabber chat / IRC channel (I prefer this last one) to communicate all, both mentors and students
  4. Emails should be used as the last option if all the above don´t work
• Self-controlling: create a weekly questionnaire that the student should complete for himself to see if he is doing good. It should contain things like
  1. I am on track with the project´s planning?
  2. Have I posted in the forums this week?
  3. Have I uploaded all the code to the CVS/SVN/Tracker each day?
  4. Using the tracker to complete subtasks could provide a more objective analysis of project completion
  5. Have I talked with my mentor about the status of the project this week?

Objectives

• Requirements must be closed by the mentors before the start of the coding phase
• At least midterm objectives evaluation process should be very very easy to do
• Final objectives could be a bit more subjective when it involves graphic design, etc.
• Force to have a midterm public release