|This page answers some questions asked by potential GSoC students posted to our and to our .
- 1 Basic questions on GSoC and the application process
- 1.1 What sort of projects can be chosen?
- 1.2 How much time per week will I need to put in for Audacity?
- 1.3 What level of technical expertise is required to participate in GSoC?
- 1.4 What should students have done before they will be considered?
- 1.5 What is the role of mentoring organizations?
- 1.6 How do I make a "good" application?
- 2 More detailed questions
Basic questions on GSoC and the application process
What sort of projects can be chosen?
The organisations and projects that were offered in 2008 can be found here:
For Audacity this year we want development that will help us get to a release. Some 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, and this should compensate for the fewer slots likely to be available.
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.
- . Note that you need the 'latest beta/development source code from CVS' version.
- . Note that you should get the latest wxWidgets version (2.8.9 at the time of writing).
- , and even if you don't, because we really need you to communicate with us!
We are expecting students to have fixed a minor bug, or at least to have had a go and communicated their progress and asked questions on , because we really need you to communicate with us!
Some examples of bugs you could have a go at to start with are:
- Silence Generator: the first non-zero digit should be highlighted, not the first digit, so that you can overtype more easily
- 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
What is the role of mentoring organizations?
See the Google pages 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 that 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 .
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 ideas with the Audacity developers, please .
Expect to revise your application in the light of comments from potential mentors. Expect to give evidence that you have compiled Audacity and made some small experimental change, ideally addressing some known issue. We do give help in audacity-devel mailing list on getting Audacity compiling - that's what happens with experienced developers joining too. There's more about writing a good GSoC application here, and .
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 to check all that's been asked and answered, then write to -devel list if you still need help.
- 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: Where can I find out about the architecture of Audacity?
- A: Look on this Wiki in ArchitecturalDesign and then perhaps at the pages in the For Developers category.
- Q: I don't know wxWidgets. Is that a problem?
- A: wxWidgets can be learned very quickly. See their , including a 700-page book: (this is also available as a ). 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 talk with us on audacity-devel. Asking questions about getting the Audacity compiler going 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 idea 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 stable release out. If your idea does not address that then you are very unlikely to get chosen. We have mentors for that project.
- 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 leaving contacting us to the last possible moment too, 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 and 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 of our next (still in draft) for this and similar questions about the Audacity interface. Remember too, Google is your friend, look there also 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: It's ultimately the mentors who decide whether a project is a success/failure. At the application stage we need clarity about what you expect to achieve. If we failed 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, or else had gone AWOL during GSoC.
- 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: This is our additional requirement. Other mentoring organisations don't require it and it's not required by Google. If we send an e-mail to [email protected] and we don't hear back from you, we want to reduce the risk of it being down to a dodgy ISP. If you're blaming gmail for a 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: Yes. Bookmark . We'll try and post deadlines and other important things you need to know there as they happen. That page will also have some Handy Hints to help your GSoC experience with us go smoothly. Add your own tips there if you know a good one!