GSoC FAQ

From Audacity Wiki
Jump to: navigation, search
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 answers the most common questions we're asked by potential GSoC students. Also see Google's own comprehensive GSoC FAQs, and the GSoC 2009 Timeline.
For information about our future plans and about Audacity software development, please join our developers mailing list
 
Related article(s):
  • Tip: Subscribe to audacity-devel if you want to get involved in the development process right now.


Contents


Basic questions on GSoC and the application process

What sort of projects can be chosen?

For Audacity this year we want development that will help us get to a new formal release. Some very helpful suggestions can be found on our GSoC ideas page.

We know that most programmers will be wanting instead to add one big new feature. Well, in our opinion there is as much if not more creativity and skill in the 'less glamorous' side of development. The fact that we expect fewer people to apply as a result of our focus on quality this year means that people who are interested will have more chance.

The organisations and projects that were offered in 2008 can be found here:

http://code.google.com/soc/2008

How much time per week will I need to put in for Audacity?

We want you to treat it like a full time job. We have some flexibility, in that it is results rather than time that matters, but for Audacity don't plan to be doing a full time job or writing up your thesis and GSoC in your spare time.

What level of technical expertise is required to participate in GSoC?

The level that could reasonably be expected of better than average computer science degree students after their first year. Realistically, given that GSoC is competitive, we'd regard the minimum programming skill to be such that at least one programming project of 1000+ lines should have been completed as part of coursework. Applicants should mention at least one significant program they have completed on their application. If you don't enjoy writing and debugging programs, don't apply.

We're not expecting students to already be familiar with the speciality of sound processing for Audacity work, or with writing GUI code, or with audio file I/O, or with preferences etc etc. We are expecting somebody who will 'have a go' at any of those, calling on expertise from the team as appropriate.

What should students have done before they will be considered?

We need students to have compiled the Audacity HEAD source code before they are accepted as a student.

We expect students to submit at least one patch that fixes (or largely fixes) a minor bug, in sufficient time that it can be committed to our code base before GSoC applications end. You will need to keep us posted on audacity-devel of your progress with the fix, and to subscribe to the Audacity-SVN Google Group, so you are aware of all changes being made to the code.


We'll ask you to shortlist some bugs you'd like to have a go at, and then get you started on one of those. These are some examples of bugs that would be appropriate:

  • Silence Generator: the first non-zero digit should be highlighted, not the first digit, so that you can overtype more easily (now fixed, but plenty more remaining)
  • Greater prominence / bright colour for arrows indicating shifting behind zero
  • Timer Record needs to remember the last scheduled duration
  • Minimum and maximum frequency display in Spectrograms preferences don't work for spectrum log (f) view
Please see Release Checklist and Release checklist not aiming for 1.4 for further ideas. Once your mentor has agreed the bug you'll be working on, we'll ask you to put your initials alongside it on the checklist, to avoid confusion.

What is the role of mentoring organizations?

See Google's GSoC FAQ for precise details.
- We select the applications we like the best.
- We provide a mentor. The mentor is there to advise on implementation choices, making sure the student has the information they need.
- We, particularly the mentor, evaluate the work and confirm to Google that the student has done the work satisfactorily, which is the basis on which Google pays the student.
- We help as best we can via our developers' mailing list.

How do I make a "good" application?

Whatever mentoring organization you choose, the best way is to get in contact with its developers and discuss what you would like to do as a project with them. Do this well in advance of sending in your application. The results of that discussion will lead to a much stronger application. To discuss your project ideas with the Audacity developers, please write to our summerofcode e-mail address.

Expect to revise your application in the light of comments from potential mentors. We'll need evidence from you that you have compiled Audacity and made some small experimental change, ideally addressing some known issue. We'll expect you also to join our audacity-devel mailing list and take some part in our development discussions. That list is also the place to get help compiling Audacity first time around - that's what happens with experienced developers joining too.

To write that winning proposal, think first and foremost about what selection criteria the mentors will be looking for. Second, include concise details of all your relevant academic, industry, and/or open source development experience, and of your proposed development methodology. The following are worth a read:


More detailed questions

These are brief answers to some of the more detailed questions we've answered on audacity-devel mailing list. Have a look at our audacity-devel archive to check all that's been asked and answered about GSoC. If you have a question you can't find the answer to, please ask us as soon as possible.


  • Q: Am I good enough for GSoC?
  • A: Convince us you are! If you give us evidence that you've compiled Audacity and then made some modification to Audacity, you're ahead of most people.



  • Q: I don't know wxWidgets. Is that a problem?
  • A: wxWidgets can be learned very quickly. See their documentation, including a 700-page book: Cross-Platform GUI Programming with wxWidgets (this is also available as a PDF download). If you've not used wxWidgets before, spend some time getting familiar with it, so that knowledge shows in your application. If you're unsure, talk it over with us.


  • Q: How do I fix this compiler error that I see....
  • A: Check our compilation instructions and the Windows and Mac compile.txt files in the source code if you have not already, then ask us on audacity-devel. Asking questions about getting Audacity compiled won't harm your chances. It shows we don't need to worry about you getting stuck and not letting us know.


  • Q: I want to tackle this HARD problem from your ideas list. Is it too hard for me? Is it even possible?
  • A: Only you can tell if its too hard for you. We believe the basic idea is perfectly achievable by an advanced student. Talk it through with us, and spend time understanding the problem. Convince yourself you can do it, so you know how much to offer to do, and then convince us you can. Beware of not giving us evidence that you can compile and modify Audacity whilst you focus on the harder stuff. Beware of not giving us evidence that you can interact with our community.


  • Q: I would like to do THIS project from your ideas page. Has it already been taken? Is there a mentor for it?
  • A: Until the application deadline there is no such thing as a project being 'taken'. As you will have seen from our Ideas page we are mainly interested in getting our next formal release out. If your idea does not address that then you are very unlikely to get chosen. We have mentors for listed projects.


  • Q: I've not written a program with more than 1000+ lines before. Is that a problem?
  • A: Yes. Talk it over with us. There may be a way forward all the same. What we really need is evidence that you will be successful in your project. If you're relatively inexperienced and also leave contacting us to the last possible moment, there's no chance at all.


  • Q: I'm a graduate student and I'm doing research in Audio/DSP. Can I propose this extension to Audacity which sounds awfully like the brief for my academic research project?
  • A: That's unlikely to be accepted this year because we're trying not to add big new features. Our focus in GSoC is on projects that make many small incremental improvements which bring us closer to release. Do contact us all the same. Even if we can't mentor you for GSoC, we'd like to know how you're using Audacity.


  • Q: What is Cleanspeech?
  • A: See this page of our next Manual (still in draft) for this and similar questions about the Audacity interface. Remember too, Google is your friend, try a search before asking.


  • Q: I've posted an application using the GSoC Student Web app, and I'm being asked to clarify what features I'm committing to and what features are optional 'if time permits'. What does it mean to commit to a feature? Does it mean I'll fail if I don't deliver a feature I commit to?
  • A: At the application stage we need clarity about what you expect to achieve. What you commit to is what we expect to see, and the committed to outcomes need to interest us. If we fail a student who committed to a feature and then didn't deliver, it would usually be because they'd also claimed skills/experience they didn't actually have, not submitted status reports (at least weekly), or otherwise not kept in touch with us throughout their project. We pretty much don't expect the 'if time permits' features to be done, as everyone underestimates how much work is involved in programming. In discussing the proposal we might ask that an 'if time permits' feature be made central and a planned feature we're less interested in be demoted.


  • Q: I want to send in some source code too, along with my application. Do I send it with the application or do I link to it?
  • A: Clear bullet points are often better than pseudocode to specify what the code will do. Real code should usually be hyper-linked to, and in your application make sure to tell us if it already runs in Audacity or is a separate program. We currently have some questions for Google about content that is linked to - can we access it when we browse the mentor app, or does it change after the application deadline? - so use it for evidence to back up your claims on your proposal, rather than for content that absolutely has to be read for your proposal to have a good chance.


  • Q: Do I really need a gmail (or googlemail) account?
  • A: Yes, we require this, although other mentoring organisations do not, and it's not required by Google. We can fail an applicant if we don't get a prompt reply to e-mails, so we want to reduce the risk of this being due to an unreliable service provider. If you're blaming gmail for your failure to communicate, Google have the option of looking into it if we ask.


  • Q: I'm pressed for time. Is there a simple way to keep up-to-date with what's going on with Audacity and GSoC?
  • A: If you're too pressed for time now, will you be too pressed for time to participate properly in GSoC during the time it runs? We expect you to treat GSoC like a full time job during the time it runs. In terms of keeping up to date with audacity development, you need to subscribe to audacity-devel. If you just want GSoC news, you can bookmark GSoC News and Tips. We'll try and post deadlines and other important things you need to know there as they happen.
Personal tools

Donate securely by PayPal, using your credit card or PayPal account!