From Audacity Wiki
< User:James
Revision as of 11:34, 22 March 2009 by James (talk | contribs) (fluency in othe rlanguages a skill...)
Jump to: navigation, search

These are my own tips to students applying to GSoC 2009. They shouldn't be taken as speaking for Audacity as a whole. Last year I was a mentor, but because of time constraints it's unlikely that I will be this year. The people who will actually make the decisions this year are Martyn, Michael and Vaughan.

I've put these tips on a wiki page so that if several people ask the same questions I can point them here.


What's behind the choice of projects on the ideas list? In 2008 we went the normal GSoC route, and we invited new big-feature proposals. When new features are added there are ALWAYS rough edges. We ended up with more rough edges after GSoC 2008 than before. It was good, but it's not sustainable. We need to have fewer rough edges after a GSoC than before. That's particularly true as a GSoC takes significant developer time away from our normal development work.

That means, at least in my opinion, that we need to front load projects with smoothing out of rough edges. I'm actually personally keen on smaller new features still being added during a GSoC, but I'm adamant that we need to be closer to release after a GSoC than before.

Improving Chances of Acceptance

  • Make the proposal your own rather than just reflecting the ideas back to us. How do you do this? A lot depends on what your background is. If you are already an active user of Audacity, pick bugs, niggles, issues that matter most to you as a user.
  • Make a proposal that you'd enjoy doing.
  • Reduce risk.

If I were proposing to Audacity, because I use Audacity mainly for the spoken word rather than for music, I would be proposing a project that improved Audacity for that use. It would be made up of small features, each useful in itself that as a whole make Audacity better for me. I'd commit to fixing some specified bugs and niggles that affect my use by the mid term, including some P3s and P4s and some I'm aware of that aren't even on the list (bonus marks for that I think). I'd ask for flexibility to substitute other bugs/niggles by prior agreement with the mentors if some prove too hard. I'd propose a colouring improvement to the spectrogram that lets me see 'breath sounds' better, a small improvement in labels - a feature I use a lot, and a very simple variant on truncate silence that requires an extra parameter - rather as tone and chirp are related. The three features are each about 3 days work and are the riskiest part of my proposal. I'd sell the proposal as 'Improving Audacity for Vocal work', and point out that under the hood it is a combination of Bugfix Superstar and UI De Niggler.

  • Platforms If you are prepared and able to work on both Linux and Windows, that is a big plus.
  • Special expertise If you have a special expertise, you could get credit for it by a project proposal which uses it in some way. In 2009 this needs care, since we also need to structure the project in small pieces. Examples, if you have LISP skills, work on the Nyquist area is good, if DSP expertise - spectrogram and equalizer are good targets for some work, if you're fluent in more than one (spoken) language, something that uses that expertise could be good.
  • Be easy to mentor, whatever your skill level We don't have time for games, for guessing what you have trouble with and what you find easy. Being straightforward helps a lot. If you think we are being stupid, we'd like to know that too!
  • Get credit for any work you have done already Make sure to mention work you have already done on Audacity code in your proposal so that it gets counted. We might not match it up otherwise. As an absolute minimum we will need evidence that you have compiled Audacity - last year most people we considered seriously provided more.
  • Be good for the project The best programmers are often also competitive, and this can present in ways that are damaging. Getting accepted is a competition, but one of the criterion is 'do you help the team and the project work well'?

If you're wondering about the optional questions in the form, they're an experiment, new this year. It's good to answer them, and don't write an essay where they say 'briefly'.

  • That awkward question about time commitment. You need to be treating Audacity as you would a job during the time. If you have other commitments too, it could be it's not appropriate to do GSoC. It's best to find out sooner than later, so discuss with us and propose a clear plan. We need to be confident that we will see good spin offs at the mid term. We've been told that "when in doubt, fail people at the mid term rather than be lenient". The mid term is a vital stage in the program. You need to be doing well at that stage.
  • Easy to assess Are the results of your project easy for us to assess? If not, can you change the project slightly or add to it in some way. For a GUI improvement, posting before and after images on our wiki might help. If you've been optimizing code, do you give us before and after figures that we can check?
  • What gives a good payback on effort? We're not automatically marking the hardest project higher than a less hard project.
  • Earn committer status during the application stages. With Audacity this is easier to do than in some large projects. I got committer access through submitting memory leak fixes, and then went on to make other changes. The changes were not contentious, and it was less work for the team to let me make the changes directly than to apply them each themselves.
  • Don't propose a complete re-write. If your plan is to rewrite Audacity from the ground up, you have a steep hill to climb to convince us that there will be a good result.
  • Investigate what features are unfinished. Only some are listed on the ideas page.

Alternatives to a points system for bugfix superstar

One alternative to a points system is to provide some analysis of the bug list (and aim tos) as they currently are.

Showing you've looked at the bug descriptions and have an idea of what might be involved gives us more confidence you'd be a good bugfix superstar than 'I will fix 15 bugs by the mid term' does. However, actually fixing 3 bugs before acceptance and saying 'I will have fixed 7 more by the mid term' is good and makes a detailed breakdown of the bug list less relevant to us. We'll know you understand what's involved. If there is some class of bug that you wouldn't be able to tackle (I won't do mac-only bugs, I won't do bugs that are hard to reproduce) it's worth saying so in the application.

Most likely Bugfix superstar will become a part of a project rather than the whole project. That's just my opinion.