Difference between revisions of "Google Summer of Code with Audacity"

From Audacity Wiki
Jump to: navigation, search
 
(One intermediate revision by one other user not shown)
Line 32: Line 32:
 
=== Submit pull request(s) ===
 
=== Submit pull request(s) ===
  
Choose an [https://github.com/audacity/audacity/issues open issue] on GitHub and try to fix it in Audacity's code. Submit your fix as a pull request (PR) on GitHub and make any requested changed in order to get it merged.
+
Choose an [https://github.com/audacity/audacity/issues open issue], preferably from the [https://github.com/audacity/audacity/projects/15 Community Contribution project] on GitHub and try to fix it in Audacity's code. Submit your fix as a pull request (PR) on GitHub and make any requested changed in order to get it merged.
  
 
The pull request doesn't have to be massive, but we want to see more than just a few lines changed. Ideally it should affect areas of code that relate to the project(s) you are applying for. If it affects code in multiple parts of the program then that's even better! Alternatively, you could submit multiple pull requests, each affecting a different area of code.
 
The pull request doesn't have to be massive, but we want to see more than just a few lines changed. Ideally it should affect areas of code that relate to the project(s) you are applying for. If it affects code in multiple parts of the program then that's even better! Alternatively, you could submit multiple pull requests, each affecting a different area of code.
Line 58: Line 58:
  
 
Proposals submitted after the deadline cannot be considered. Draft proposals cannot be considered regardless of when they were submitted.
 
Proposals submitted after the deadline cannot be considered. Draft proposals cannot be considered regardless of when they were submitted.
 +
 +
=== What to expect if your submission is successful ===
 +
 +
If your application is successful, the first step will be to have an initial meeting with one of the full time designers as well as your mentor (they will make contact with you to set this up). The designer and mentor will provide an initial specification that will outline all aspects of the desired functionality (core feature, accessibility, associated shortcuts, etc.). This specification will then be discussed with you and potentially revised to ensure that the scope of the project is not too large. Throughout the process of development, you will be encouraged to share updates with relevant team members to ensure that your work receives testing, development advice and design support.
  
 
[[Category:For Developers]][[Category:GSoC]][[Category:Feature Planning]]
 
[[Category:For Developers]][[Category:GSoC]][[Category:Feature Planning]]

Latest revision as of 22:01, 12 March 2022

Introduction

Google Summer of Code (GSoC) is an annual program that offers money to contributors who successfully complete coding projects for open source organisations like Audacity. Applicants should be familiar with Google's requirements as well as our own. Check out the blog posts by previous Audacity GSoC contributors to get an idea of what could be expected of you.

Changes for 2022

As per Google's announcement, this year for the first time:

  • The GSoC program is open to both students and non-students as long as you are at least 18 years old and fairly new to open source. See Google's FAQ for full eligibility requirements.
  • Projects can be medium (~175 hours) or large (~350 hours) in size, usually completed over a period of 12 weeks.
  • The 12 week coding period can optionally be extended by up to 10 weeks (i.e. 22 weeks in total), although this requires approval by both the contributor and their mentor.
    • We will consider extending the deadline to account for time when you are unavailable during the coding period, such as holidays or classes, but we do not advise using the extension as a way to attempt a project that would take you longer than 350 hours to complete. Please be very clear about the expected end date in your proposal(s).

Applying to participate

Audacity is popular software and in past years we have received many more applicants for GSoC than there were places available. Please only apply to us if you are certain that you would like to do a project with us. You may want to consider applying to other GSoC organisations instead of / as well as Audacity.

Join the Discord server

Join the Audacity Dev Discord Server and introduce yourself in the GSoC channels. Use this opportunity to ask for any help you need with the remaining parts of the application process, such as compiling Audacity or writing a proposal.

Compile Audacity

See https://github.com/audacity/audacity/blob/master/BUILDING.md. If you encounter errors, try pasting the error messages into a search engine to see if there is a known solution. If you're still stuck, ask for help in the Discord Server's #compiling channel.

Tip: Always remove potentially identifying information from screenshots, build logs, or command line output before you share them online or paste them in a search engine.

Submit pull request(s)

Choose an open issue, preferably from the Community Contribution project on GitHub and try to fix it in Audacity's code. Submit your fix as a pull request (PR) on GitHub and make any requested changed in order to get it merged.

The pull request doesn't have to be massive, but we want to see more than just a few lines changed. Ideally it should affect areas of code that relate to the project(s) you are applying for. If it affects code in multiple parts of the program then that's even better! Alternatively, you could submit multiple pull requests, each affecting a different area of code.

Write draft proposal(s)

Write your proposal in Google Docs and share a link with us via the GSoC Dashboard. Make sure sharing permissions on the proposal document are set to "Anyone with the link can comment". Ask potential mentors to review your draft proposal.

Draft proposals can be submitted via Google's GSoC interface from the start of the application period. We encourage you to submit early, as proposals can be revised based on comments from us. There won't be time for comments by us and revisions if you submit close to the deadline.

Here are some boilerplate comments we might have:

  • 'Please be clearer about what your new code will do for users.'
  • 'Have you looked at feature X already in Audacity?'
  • 'Where is the timeline?'
  • 'No, a project that only delivers anything useful at the very end of it isn't going to work'.

If your proposal is just a cut and paste from our ideas page, it won't get very far.

Your project timeline doesn't have to be super detailed, but it must show exams/internships/holidays that you plan to take during the coding period, or other known significant calls on your time, and you must distinguish between what you are planning to achieve by the mid term evaluation from what you plan for the part after. We look for a project plan that delivers something of some value to our end users by the mid term. That is an insurance for both you and for us. Planning for everything to come together only by the end of the project is too high risk.

Submit your final proposal(s)

Make sure you upload a final PDF version of your proposal(s) to the GSoC Dashboard before the deadline. You may submit up to three proposals for us or other organisations to consider. We would then choose which one of those projects, if any, we would like you to complete.

Proposals submitted after the deadline cannot be considered. Draft proposals cannot be considered regardless of when they were submitted.

What to expect if your submission is successful

If your application is successful, the first step will be to have an initial meeting with one of the full time designers as well as your mentor (they will make contact with you to set this up). The designer and mentor will provide an initial specification that will outline all aspects of the desired functionality (core feature, accessibility, associated shortcuts, etc.). This specification will then be discussed with you and potentially revised to ensure that the scope of the project is not too large. Throughout the process of development, you will be encouraged to share updates with relevant team members to ensure that your work receives testing, development advice and design support.