Note: This article is a work in progress. Please feel free to edit it and add further comments and suggestions.
Suggestions from skype chat and mentor debriefing
- Ask all GSOC applicants to propose at least one bug fix by attaching a patch to the tracker issue. Straightforward/easy-to-fix bugs could be identified and a list provided for GSOC applicants.
- Create a GSOC students course on moodle.org for students for applicants and accepted students to experience Moodle as a student.
- Have a Jabber chat room for GSOC mentors and students.
- Require students to maintain a blog and post an entry at least once a week summarizing what they've been working on, what problems they've run into, and what they're planning to do next. The blog could be on moodle.org or an external blog. Blog entries should be tagged "gsoc", as Joey did (see http://moodle.org/tag/index.php?tag=gsoc )
- Set out a schedule of communication to ensure students are aware that we expect them to be keeping us up to date and not just working away on their own. Emphasising that we will take unplanned failure to communicate seriously
- All students must report in a common place weekly so that they're aware of each other as well.
- Have a much higher visibility of projects and students and what they're doing. Take ideas from Silverstripe on how to treat students. Silverstripe absolutely treat their students like rock stars which has made them much more likely to continue contributing after GSOC, they give them silverstripe t-shirts and blog about how awesome they are and get the students to write about it, it builds a much stronger bond in the community, rather than just having each student communicate with one or two people mostly privately.
- Push students to get more involved in the community and make use of the community bonding period.
- Post progress reports of students' projects.
- Create a list of exactly what we expect of students (1. blog, 2. weekly meeting with mentor, ...) This would particularly help first-time mentors.
- Push for co-mentoring for as many projects as possible (but make sure the co-mentors know exactly what their division is in case they both think the other person is doing something).
- Come up with common milestones for ALL students that are the same (e.g. public weekly report).
- Utilize the tracker better, with project milestones as tracker subtasks.
- Provide support for potential students in the application phase, hang around the IRC channel, help create patches etc.
- Get organised and come up with a list of student projects for GSOC a lot earlier.
- Provide a list of projects of varying complexity and give the student projects page a more generic name, such as "Development projects", "Ideas", "Projects",...
- Encourage the community in coming up with ideas for projects which interest them and reporting them in the tracker. Feature requests with lots of votes can then be added to the projects page.
- Ensure that everyone in the community understands the value of voting for issues (have a votes publicity campaign).
- Tim: In open source, it is not so much a question of how much code you have time to write yourself, but how much code you can get added to the project by encouraging other people as well.
- Martin: Hopefully our growing experience will make it easier to spot quality students each year in future.
- Anthony: Perhaps we can encourage schools (secondary and higher ed) to get students involved in working with Moodle (how to report bugs, develop a patch etc.) as a way of preparing students for GSOC. I would be happy to work with teachers interested and am piloting such a project with a high school class in Houston.
- Helen: Let's look for ways of encouraging students/new developers into Moodle development all year round, rather than just for GSOC and GHOP.
From David Horat and Anthony Borrow:
- All primary mentors should be regular core developers.
- Create our own questionnaire
- Remark how important is to have time to develop a full time job as the SoC
- Remark how important is to have willpower to develop a work from home or try to search other places to work
- Remark how important is to do the job after accepting it and not wasting a slot that another student could have used
- Remark how good is for the student being successful in the GSoC (money, visibility, good for CV, recommendation letters, etc.)
- 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.)
- Forums - Ability to communicate clearly and effectively on Moodle.org forums
- Tracker - Ability to create a tracker issues and effectively use the tracker as a means of communication
- 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
- 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
- Should projects like the IDE Project really be considered a Moodle project?
- Check students public activity (forum posts, tracker comments, code updates, etc.)
- Keep using the Wiki pages as the main projects documentation, which must be up-to-date
- Force the student to blog publicly each day/2 days about his progress and in what he has spent his time working
- Use a Jabber chat / IRC channel (I prefer this last one) to communicate all, both mentors and students
- 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
- I am on track with the project´s planning?
- Have I posted in the forums this week?
- Have I uploaded all the code to the CVS/SVN/Tracker each day?
- Using the tracker to complete subtasks could provide a more objective analysis of project completion
- Have I talked with my mentor about the status of the project this week?
- 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