GSoC Planning

From Audacity Wiki
Revision as of 21:50, 16 September 2008 by Richardash1981 (talk | contribs) (Final Polishing First?: saome fairly radical ideas for people to play with)
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)


Final Polishing First?

  • 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.
Mchinen You might even be able to get people to get on this before gsoc starts - make it an optional part of the application to fix an assigned bug. This would provide a means to check the applicant's code competence as well as get him/her familiar with the codebase. Of course this will require the Audacity mentor side to be on top of applications by assigning bugs that relate to the project proposal. It might also make sense to have a dedicated 'fixer-upper' student slot that just work on killing bugs as well as making audacity speedy. This 'handyman' spot might even interact with the other student's projects to fix bugs as well as blog about them - I think this would make the position more attractive as well as the student interaction a more regular thing.
LRN: Bad idea (handyman spot). Audacity developers are the 'handymans'. And mentor is the one who watches a project. I mean, anyone can tell the student what to do and/or give advices and directions. Actually doing something to help/fix is up to mentor. And it is assumed that mentors have well-developed intercommunication and are coordinating their work. But an optional requirement of involvement before GSoC (fixing bugs, improving documentation, etc) is a good thing. It would really help students to get their applications accepted. Just make sure you announce the whole thing ~ a month before you start publishing (and accepting) project proposals, which itself should begin a month before the application submitting period starts. So - 1 month to prove you're useful/skillful (and to get to know the code, and maybe even come up with your own project proposal) and 1 month to do preliminary work on the project. It may sound unfair (normally students are not supposed to be working on a project before application period starts), but consider the fact that most of this happens before Google publishes a list of accepted organizations, so for a student it is risky to rely on such preliminary work as a way to get into GSoC.
James: We can't run projects which have high degree of mutual interactions, so having one person building the walls and another smoothing and plastering the same project can't be done. Asking each applicant for a months worth of bugfixing before GSoC is announced won't fly either. In 2008 we got proof that students could compile Audacity and make a trivial change. In 2009 we can be more demanding and require some improvements / fixing / polishing too during the selection stage. More important, to get more of this done, we need more of that kind of work to happen in the project too. I'd love to be a student being paid to add a new feature, a mentor giving some help, being required to get it to a good state by the end date but no strict requirement to get it to release readiness. The likely outcome if we do this is that each year we'll add five good features with rough edges - so to be sustainable students need to be smoothing more rough edges whilst GSoC is running. It needs working into the project descriptions somehow.
Richard: Looking at other projects, I see roughly two approaches to this kind of problem. The first is to leave the polish to other people and other times - these are the projects where a student turns in something that basically works, and at the end of GSoC the process of getting it accepted into mainline code starts. These projects often have relatively low success rates in terms of code released to users (regardless of whether GSoC succeeds or fails). This obviously is not a mechanism that will work for us. The other approach used is to make the second part of the summer of code predominately code review and polish. So in these cases the functionality needs to be basically written by the mid-term point, and the second half of the summer becomes multiple rounds of submitting patches to go into mainstream, feedback from the "gatekeepers" and revision. Whilst our process of early inclusion into CVS doesn't exactly suit either process, I think we might need to be nearer the second model than the first, i.e. scope the coding more with finishing functionality by midterm, and spend the second half of the project getting the code to a releasable state. The fact that Google can't pay for documentation work is a bit of a headache here - I'm a firm believer in the idea that if you force someone to write a user manual for something they will improve the usability of their code substantially because it is easier than explaining how it works to start with. Maybe we need to be radical and target going to a full released beta about a week before SoC ends, so that students are still around when the bug reports go in. At that point does anyone whose code doesn't make the beta fail GSoC?

Selection Criteria Page

  • 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.