GSoC Student Guidelines
From Audacity Wiki
|Google Summer of Code (GSoC) is Google's program for promoting Open Source Software development. Audacity was a mentoring organization for five students for Google Summer of Code 2008, and mentored two students in 2009. This page contains our Policy Guidelines and Requirements for Audacity Student Participants in Google Summer of Code.|
|For information about our future plans and about Audacity software development, please join our developers mailing list|
- We expect you to join the audacity-devel mailing list. Most discussion of your projects should be on this list, but you can continue to use our summerofcode email address to contact mentors and admins directly.
- An email forward is setup for GSoC students at [email protected].
- When we need to contact you directly, we will use the gmail or googlemail address you gave us, so check those regularly.
- Different mentors in Audacity may have different views on the same issues - it's part of the nature of open source. Vaughan is our GSoC Admin and has overall responsibility and authority for our GSoC involvement, so makes the "final decisions". This helps keep things moving, so we make decisions now rather than taking too long to reach an "optimum decision". We hope this works as well for you as it does for us.
- We encourage students to start a User: page on this Wiki (that is, "please introduce yourself"). Students must start a progress page for their project and call it as per the title on the GSoC Projects page. See the GSoC 2008 Projects page to get the idea. Also see our Wiki editing tips on GSoC News and Tips.
- Weekly status reports of the "this is going well... and this isn't...." kind to be sent to [email protected] (so this will include your mentor). These should be brief and focused.
- We are considering requiring weekly updates on a wiki page from both students and mentors, staggered though the week (say Saturday for one and Wednesday for the other) with corresponding posts on audacity-devel, enabling tighter monitoring.
- We are also considering having a collaborative calendar for all students and mentors to register milestones, planned absences and so on.
- Keep a record of code you write so that you are ready to upload it to Google at the end of project. We'll ask for tarballs of your code at the mid-term as a practice run.
- We'll freeze "kick-the-tires" alphas semi-monthly, on the 1st and 15th, for all three platforms, to test the code. This means that on the designated dates, your latest code that's at least partially working should build without breaking anything.
- We expect documentation of your contributions at both mid-term and final stages, both from an 'end user' perspective and from a 'developer' perspective.