GSoC Mentor App - 2008
This is a first draft of the proposed text to send to google to apply for mentoring status:
- Describe your organization.
We are developers of the Open Source Audacity sound editor.
- Why is your organization applying to participate in GSoC 2007? What do you hope to gain by participating?
GSoC looks to be a very effective way to get a developer giving full time attention to Audacity, coding on a focused task. It looks to be win-win, good for the student and good for us. As well as the direct improvements to Audacity from the student, which would be hugely welcome, we also hope to interest more people in contributing, through the publicity around GSoC.
- Did your organization participate in GSoC 2005 or 2006? If so, please summarize your involvement and the successes and failures of your student projects.
No. We weren't involved in 2005 or 2006 GSoC.
- If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?
No. We didn't apply. We weren't ready.
- Who will your organization administrator be? Please include Google Account information.
TBD. I (JamesCrook) am more than happy to do it.
- What license does your project use?
GNU GPL V2 compatible. Some code is also released under a more permissive license.
- What is the URL for your ideas page?
Approved version: TBD
- What is the main development mailing list for your organization?
- What is the main IRC channel for your organization?
We don't use IRC and don't plan to for the project. There is an IRC channel on freenet, but we find using e-mail to be more time-efficient. For interactive discussion with the student, we plan to use Skype.
- Does your organization have an application template you would like to see students use? If so, please provide it now.
Yes. See SummerOfCodeStudent
- Who will be your backup organization administrator? Please include Google Account information.
- Who will your mentors be? Please include Google Account Information.
TBD. I'd prefer to be a mentor than an administrator, but am happy to do both.
- What criteria did you use to select these individuals as mentors? Please be as specific as possible.
We only chose experienced Audacity developers as mentors, people who have been involved with Audacity for at least two years. All the people in the mentor list have good experience of working with people new to the Audacity code, helping them to contribute. Most of the mentors have a sense of humor too.
- What is your plan for dealing with disappearing students?
A lot depends on the quality of the code produced by the student up to that point. We see the main danger as being a student who isn't making real progress, but says they are 'working on it'. This is what we aim to avoid and we think we can. This would likely happen well before a student disappears. One of the first tasks the student will be asked to do is to propose a structure for their work so that parts of it that are useful in and of themselves can be delivered early. The mentor will help them to reach that formulation. We aim to avoid a 'big bang' where there is nothing useful to Audacity at all until right at the end of the project. Provided there is good code at the point where a student disappears, then we have options, and there is some benefit from participating. If that happens we'll contact people on the shortlist but who didn't make it, with the option of picking up where the previous student left off. Most likely though we'll complete the code ourselves, but more slowly and recommend that the final payment is not made.
- What is your plan for dealing with disappearing mentors?
All proposed mentors already have a track record with Audacity. We think disappearing mentors is most unlikely, and we have an embarrassing over supply of backup mentors should that happen. Whilst the student works with their mentor, the progress made so far is shared with the entire Audacity team on a continuous basis, so it makes it easier for a transfer.
- What steps will you take to encourage students to interact with your project's community before, during and after the program?
Mainly through the developer list. It's a friendly place, and it's good for getting answers to tricky development problems. We want the student to get rapid feedback on the work they do, and that means primarily interactions with the developer community rather than with the much larger user community.
We do intend to do at least one major release during the time of the GSoC-2007 project and for the student to be actively involved in the process. If they're able to get some of their ideas implemented early enough in the project, they will see the feedback and enthusiasm from the users - and probably a lot of requests for 'small' extensions to their work.
- What will you do to ensure that your accepted students stick with the project after GSoC concludes?
Audacity is a hugely popular program already with many millions of downloads. People stay with the project because they want to or leave if they don't. Trying to bind GSoC students to the project in some way after they complete what they agreed to would be counter productive. Paradoxically they are more likely to stay if they are free to go. It means we as a group have to focus on making it enjoyable and rewarding to stay.