You're early!
GSoC 2016 has finished and our mentors are getting some well-deserved time to work on their own projects. We'll start preparing for GSoC 2017 in January 2017 and won't have ideas pages ready until February and won't even know if Google has accepted us to participate until later. So cool your heels a bit and spend time getting good at open source development. Get started by following the 7 steps below!
Where do I start?
Choose an organization to work with. Python has a lot of sub-orgs (In recent years, around 20-25 is normal), so this can be hard. You do need to choose a sub-org if you're working with Python; projects without a sub-org are usually rejected at selection time. See "How do I choose a project or a sub-org?" if you need help.
- Hint: Don't choose "Core python" as your default if you don't know what to do: our other sub orgs usually have a greater range of projects and mentors available!
Any open source experience will help you prepare for GSoC, so don't worry too much about what project you try first. Having experience with multiple projects isn't a bad thing, either!
Set up your own development environment. Document what you do so you can remember it later, and so you can help others if they get stuck! And if you get stuck, don't be afraid to ask for help.
Start communicating with the developers. Join the mailing list, IRC channel, or any other communication channels the developers use. Listen, get to know the people involved, and ask questions.
- In almost all cases, you should communicate in public rather than in private. GSoC is a busy time for many developers and many beginner questions get asked repeatedly. Help keep your devs less stressed out by reading what they've written already and making it easier for them to have a record of the things they've answered.
If you want to make the best first impression, DO NOT start emails with "Dear Sir." (see How should I address my emails (or Why shouldn't I start my emails with "Dear Sir")? for some alternatives and more information.)
Find some beginner-friendly bugs and try to fix them. Many projects have these tagged as "easy" "bite-size" or "beginner-friendly"
- Note that if you apply as a student with the PSF you will be asked to submit a code sample, generally code related to your project. A few fixed bugs with code accepted upstream will make your application look great!
- Having trouble figuring out which bugs are beginner-friendly? Check and see if anyone else has asked recently (usually during GSoC a *lot* of people are looking for easy bugs) and read the answer they got, but if no one's asked in a month or so, you can ask the developers via public mailing list or IRC. (Hint: don't ask privately; this is a question that other people want to know the answer to)
Some projects have beginner-friendly "bite-sized" bugs listed in the OpenHatch search engine, found here: http://openhatch.org/search/
Find bugs and report them. Hopefully you won't encounter too many, but it's always a good idea to get familiar with your project's bug reporting process.
Help with documentation. As a beginner in your project, you're going to see things that are confusing that more experienced developers may not notice. Take advantage of your beginner mindset and make sure to document anything you think is missing!
Help others. This is a great idea for a lot of reasons: explaining things can help you learn them better, demonstrating your skills as a good community member can make you more memorable when your mentors have to choose candidates, and being helpful makes your community a better place!