LICENSE (This guide was adapted from ESIP's organization guide: thank you ESIP!)
Experience shows that the best thing to help your application is to engage with the organization you want to work with early. For Orcasound you should read about contributing as a “hacker” and then introduce yourself in the #gsoc channel of our Slack workspace. The opensource guide has a good introduction how to start contributing to open source projects.
The answer is generally: Yes. We value creativity, intelligence and enthusiasm above specific knowledge of the libraries or algorithms we use. We think that an interested and motivated contributor who is willing to learn is more valuable than anything else. The range of available projects should suit people with different backgrounds. At the same time, if you have experience using your project of choice or one of its dependencies (e.g. language) make sure to let us know about that as well. The "Am I Good Enough" FLOSS manual gives a good overview of this part for GSoC.
The tips listed here can help your application. They are not required
Organizations usually favor contributors that show a regular communication with possible mentors and organizations until Google announces the accepted projects.
Establishing a regular communication is good for 2 reasons. It shows that you are a reliable contributor and that you have good communication skills. Good communication skills are an important part of GSoC since a new contributor and mentor can rarely meet in person. Please, communicate through the Slack #gsoc channel, or on github. Please, do not send private messages to mentors and organizers; if you have a question, it is highly probable another person has the same question, and they can benefit from the open discussion.
You can get started by exploring the references in the project descriptions, getting familiar with the Orcasound repositories and data, attempting some of the suggested steps and trying out listed tools, reading through the wiki and contributing missing details, resolving issues, reviewing PRs, improving code documentation and style, and adding tests. Before submitting a big code change, make sure you open an issue to discuss with other contributors.
When we evaluate an application we use the following point system to get a baseline comparison of applicants. We are providing this rubric to help you successfully apply and not miss any key components of the application process. You don't have to tick off all of these, and you can always do more, but these are our basic expecations. We will be fair, we promise, but will rate your effort from 1-5 (1 is failure to complete; 3 is completion, but with average effort; 5 is full completion with effort in the top 10% of your peers).
- 5pts Communicate with organization's mentors
- 5pts Communicate with the community
- 5pts Follow instructions and format of the Orcasound GSoC proposal template
- 5pts Properly cite the work of others in your proposal and code, including links to repos or provided code
- 5pts Provide all requested contact information (i.e. email & slack name, & github if available)
- 5pts Project title, abstract, and detailed description
- 5pts Include all requested technical details (see template)
- 5pts Include a preliminary project schedule in your proposal (ideally addressing how you will spend your time before, during, after GSoC)
- 5pts Evidence that you have time for GSoC. State the period during which you will be available to work on your proposal, how many hours per week, and list other time commitments.
- 5pts Document your development and other experience relevant to the project(s)
- 5pts Explain why you are interested in the project and are a good fit
- 5pts Submit a pull request to the existing code, or discover and/or discuss issues with the current code.
- 5pts Continue communication through date upon which accepted applicants are determined.
- 0pts Be honest! Only universal Karma points. 🙂 We are happy to see you grow in your learning process, but we also need to understand your technical skills and make sure that we have mentors that can support you in the process. Also, if we discover you were dishonest in your application, we will fail you and move on to collaborating with others.
The items here are a requirement for contributors during the summer
Communication
- Follow the contribution guidance for the repo that interests you.
- Discuss issues and feature ideas on Github or Slack before submitting a related PR.
- Commit early and commit often! Push to a public repository (e.g. Github) so that we can see and review your work.
- Actively work on our project timeline and communicate with us during the community bonding period.
- Communicate every working day with your mentor. Preferably in public using the standard channels of your project.
- If there is a reason why you can't work or can't contact us on a regular basis, please make us aware of this.
- If you don't communicate with us regularly we will fail you.
Evaluations
- Set a realistic goal for all evaluation deadlines. If you fail to meet your own goal, we are more likely to fail you in the evaluations.
- Communicate ASAP with the project mentor if evaluation metrics are unclear.
Blog
- Write a short report for us every few weeks in the Orcasound blog, discuss it with your mentor(s) and peers, and be sure to include personal goals for the next phase of GSoC. These posts will be shared with Orcasound's open source community and on our social media channels.
- Feel free to blog more often than the required amount!
Projects proposed by mentors are listed at our issues page.
Please title your proposal [IssueNumber_YourName_ProjectName]. You are free to use components from several projects ideas: select the number of the project you find closest to your interests. Be realistic about the scope. You are also welcome to propose your own idea, but first discuss it on Slack to ensure there will be mentors who can support it.
First, think about your choice of project carefully. You're going to be doing it for a couple of months, so it's important that you choose something you're going to enjoy.
Once you've made your mind up:
- Make sure you've thought about the project and understand what it entails.
- Engage with the community early. The earlier you contact us, the more feedback you will receive on your application. It may take time to review the draft proposals so feel free to ask on Slack or GitHub whether your proposed path makes sense. Also open-source code is often built in the open, so it is usual to obtain feedback within public fora.
- Don't be afraid to come up with original solutions to the problem.
- Don't hesistate to give us lots of detail about how you would approach the project, but also be succinct and convey your ideas clearly. A picture or a link may be worth a lot of words.
Overall, your application should make us believe that you are capable of completing the project and delivering the functionality to our Orcasound users and/or the broader bio/acoustic community. If you aren't sure about something, ask questions on Slack where we're happy to advise you.
Get some familiarity with the orcasound repositories and data. Test existing functions, add missing details, fix code style. Do some research on the methods and tools you plan to use. Install the needed packages and build a plan of how they will work together. Write down your algorithms in pseudo code.
The better your research is and the better you plan ahead, the easier it will be to judge how long a given task will take. For your time estimates you should also consider that you can do less during exams or other summer activities, so try to be a bit conservative. Discuss the risks of the proposal and potential challenges. How do you intend to address them? What criteria will you use to evaluate milestones (code tests, functional demo, baseline recording, etc.)? If you have never done anything like GSoC before, you will tend to underestimate the time to complete a task. We know that making accurate estimates isn't easy, but having a good plan -- including identifying its weak and strong points -- will help ensure a successful summer of coding.
Your final proposal must be submitted to GSoC as a PDF file, using this template. Your proposal should be named [IssueNumber_YourName_ProjectName] to make identification easier for the mentors. To convert a draft that you have written before into PDF you can use Pandoc.
$ pandoc -f markdown -t pdf YYYY/proposals/your-project-name.md