GSoC Planning

From Audacity Wiki
Revision as of 08:01, 15 September 2008 by Galeandrews (talk | contribs) (Only a fixed amount of time whatever the students do?)
Jump to: navigation, search


This page is to help with planning for Google Summer of Code. It's a 'brainstorming' page at the moment. All subscribers to audacity-devel are very welcome to add comments and suggestions. James 05:26, 27 July 2007 (PDT)

2009

  • James: I'm thinking of some radical changes to the kind of ideas we suggest. One of the problems is that 'final polish' is the most likely to get dropped from a project, with time trouble, and it is essential for release. So how about instead we front load each project with 'polish' to existing features, before giving go-ahead for (related) new features. For example the labels project would have needed to start out by investigating and fixing the 'dropped character' bugs. Quickload would have needed to start out by fixing the 'lost data when disk full' problem.
Gale: It would get some "boring" big fixing done, and if the project collapses we get something more useful than a quarter-complete feature. But there is only so much time in GSoC, and the polishing of new features has to be done some time, too. And I wonder if students might view this a bit negatively if explicitly stated, i.e. they are not exclusively working on that exciting new feature? For example we got some old label bugs fixed, but did it prevent multiple labels being done? And for pre-Quickload polishing you might argue the "freeze on cancelling dependency removal" should have been addressed, which would have left less time for QuickLoad itself.
  • Richard: Is it a good time to start on a "what are we looking for in students" page for next year. I think a reasonable number of applicants (especially from outside US/Europe) have mis-judged what we were looking for, and some more concrete points (based on what was said in private comments but in a general form) might help students (and us) next year. A key one is about time commitment, especially for post-grad people who don't really have a summer vac. There are also a lot of new-to-open-source people who don't get the whole fitting in / code re-use / connected open source philosophy, which I've tried to lever a number of people towards, but hasn't always worked.
    • Gale: Could also be included/linked to in the "Hints on writing a good proposal" panel in Writing GSoC Proposals. Information in situ may have more chance of being read than in a link.
    • James: I think personal opinion works well here. So a blog on it, with a link from the wiki? One thing I want to get across to students is that different mentors will have different views, so whilst I'll agree with what Richard says, I'd have a different slant on it and emphasise some other points.
    • Gale: Not sure where the blog would be, but perhaps in the bullet point with the link, one or two more or less consensual points could be given as examples of what we want. Vaughan has noticed some student lack of awareness due to not reading online material.


Carry Forward from 2008

  • All students to get gmail/googlemail accounts. Ensure it's clear that it's our requirement, not googles because this created some confusion last year. Mentors of course should have gmail accounts too, to be listed as mentors - but all likely mentors do now.
  • Integration projects (projects in which an existing library is integrated) need particular care with regard to tracking student progress. Such projects tend to be 'chunky'. Everything arrives at once. Insist on a CVS or other repository we can track transparently, not a 'remote infrequently synced repository'.
  • Find consistent naming for the two pages per project. ProjectName-Notes and ProjectName-Progress are suggested. In 2008 we didn't have consistent names.
  • After GSoC kick-off, do not add new student-submitted ideas to the GSoC Ideas page but let them instead manage their own notes page. In 2008 it was a little confusing having some edits to the ideas source.
  • Ditch the 'expression of interest' page. It didn't serve a useful function.


Review Notes 2008 (Pruned)

  • James: More GSoC Ideas has over ten times fewer views than GSoC Ideas.
    • Gale: Make the link to More GSoC Ideas more prominent, or list a summary of all projects on one page with links to them, marking the provisional ones as such?
    • James: Link to more prominent.


Recurring Planning Needs

  • In the run up to GSoC we wanted to get our developer documentation into good shape. This is particularly important for new features like the plug-in interface. Help with bringing the Doxygen documentation back up to date would be appreciated and is also a good way of learning the code. We'd also like to go further and have diagrams and more written documentation that shows how things work.
  • We can always do with new ideas on the ideas page. Suggestions that have an element of novelty to them, that can be completed in the time frame are particularly welcome. We feel it's important that projects have both an aspect which is fairly straightforward to complete in the time as well as a stretch goal. We need to get something complete and usable out of each project, whether it goes superbly or whether there are difficulties.
  • We would like someone to help us design a half-page flyer for Audacity GSoC which we can put on notice boards in computer science labs in universities. If there are multiple offers to do this, then we'll vote on the flyer to use on the audacity-devel mailing list.
  • Some of the projects are likely to be an overlap between Audacity and wxWidgets, Portaudio or Jack. In those cases, if the project is being administered and mentored by Audacity, it would still be very useful to have a second mentor from the overlap project already lined up to give advice.