This summer, i would like to mentor a student in the Google Summer of Code program for 2009. The following document is a list of requirements for a submission and a description of how the mentoring will work this summer.
For other mentors, please feel free to use this plan for your mentoring strategy as well
Students
This section explains the role students will have.
Application
Given the success and popularity of the Features Process, this year, the application will be formatted exactly like a Feature. The end goal is to produce a small feature that can be implemented in the two month period in time for Fedora 12.
Requirements
The actual content of the Feature is entirely up to the student but it needs to include the following.
- The Feature needs to meet the requirements of the Feature Process
- Your mentor will help you fill in the details
- It must include a development and test plan to span two months, not five-six
- You will be responsible for maintenance of the Feature for at least one year
- You will also need to find a replacement maintainer to take over after that.
- It needs to be approved, or at least unofficially approved, in time for the beginning of GSoC
- This just means the Feature Wrangler needs to accept the Feature page
- It must be 50% complete in order to receive the first payout
- It must be 100% complete in order to receive the final payout
Ideas
I can put some potential ideas here.
Most importantly, though, is that it has to be an idea that inspires the student. Based on my totally non cited information, the most successful projects are ones that the student comes up with themself.
Here's how to figure out the brainstorming process. Start with "Wouldn't it be cool if Fedora had X?" where X is anything that has to do with an operating system.
The only objection i have is proposal for a project that would have a better upstream elsewhere. For example, a proposal to provide better photo management for Gnome would be rejected because it belongs in the upstream Gnome primarily. A proposal to provide a cross DE, cross distro, cross platform Photo management would be far better received.
Your Mentor
Since this possible process is open to both new Fedora Contributors and experienced ones, your Mentor will do many different things. For experienced contributors, your Mentor will play more of a background role, taking status reports and making sure you have the necessary tools to do your job. If you are new to Fedora, then your mentor will at least help you with the following:
- Help prepare your Feature so it will meet the Guidelines
- Assist you in getting the right accounts and groups set up in order to do your job.
- probably more - fill this in
Mentors
Why?
One of the issues that keeps reccuring during the GSoC program is how to encourage students to participate, keep within their schedule, and get visibility for what the Student is doing. This will encourage the Student to interact more publicly with other people over the summer, and make it clear what the Student has been up to. Due to the high visibility of the Features Process, it will also give the student something to look back on in the Fall when Fedora 12 is released.
How?
Another issue that is faced is how to make sure GSoC code doesn't turn into abandonware without dropping the student into a larger project that may be too complex. One trick is to make sure that the results are put to use as soon as the Student commits it to a source control repository. Another way is to require usability as one of the core requirements. In order to break this down into a chunk that a single student can tackle over a single two month period, a Feature seems like a good candidate. Please keep the following in mind when guiding a student in making an application:
- The end goal is integration in Fedora, therefore the deliverables should reflect this.
- There are only 2 months, keep it short and simple
- The feature should encourage continued maintenance from the Student, the application should reflect this in writing
- Remind the student that many Features actually can slip. The Features Process is designed to let Features hang in limbo indefinitely until the work is complete.