GSoC Student Guidelines

From Audacity Wiki
Revision as of 08:09, 19 March 2009 by Galeandrews (talk | contribs) (Audacity accepted)
Jump to: navigation, search
Audacity has been accepted as a mentoring organisation in Google Summer of Code 2009. This page contains our Policy Guidelines and Requirements for Audacity Student Participants in Google Summer of Code. Prospective students should review all our GSoC documentation listed below and contact us now to discuss their proposal.
For general information about our GSoC involvement, please join our developers mailing list
Related article(s):
  • Remember, write to our summerofcode e-mail address and discuss your ideas with us now. This greatly increases your chance of being accepted.

  • 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 build "kick-the-tires" alphas every two weeks, for all three platforms, to test the code. This means that on the designated bi-weekly 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. (Added for GSoCs post-2008.)