Guidelines for student applications
We’re participating in Google Summer of Code as a sub-organization of the Python Software Foundation. As such, each student application should follow the PSF guidelines.
Here are some useful links to learn more about the requirements from the Python Foundation. Please read them thoroughly to make sure you’re fully aware of them.
- General homepage to get you started: https://wiki.python.org/moin/SummerOfCode/2016
- Commitment expectations: https://wiki.python.org/moin/SummerOfCode/Expectations
- Application template: https://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2016
There are two main points for every application on which we’ll base our eligibility criteria. First, the actual written proposal you’ll submit to Melange with the research on your chosen topic and the schedule you plan following these months. Second, the code samples you’ll provide that will let us evaluate if you’re capable of accomplishing your proposal.
Advice while making your application:
- When addressing mentors, please state the project you chose if you’re using general channels like firstname.lastname@example.org or direct mails. We have three different projects this year at Scrapinghub: Scrapy, Portia and Splash, with some overlapping mentors between them, so this will help us handle your messages more efficiently.
- Your proposal is a great opportunity to show us your research skills and dedication, so try to investigate as much as you can on your own and make narrower questions by then.
- Hard ideas are favoured over easy ones, but quality proposals and development skills are going to be ranked even higher.
- It’s recommended you start an early draft of your proposal somewhere publicly accessible, so mentors and users can review it and provide feedback. It’s easier to answer questions or help you if you get stuck knowing your work beforehand too.
- Our preferred channels for communication, listed is decreasing order, are: Github > Mailing Lists > Direct Emails > IRC. If there isn’t an open issue for your idea yet, we encourage you to open it and discuss your thoughts there. Same goes for pull requests, if you have code you want to show us sending a pull request is the best way to do it. Prefix any PR title with “[WIP]” (i.e. work in progress) if your work is not ready to be merged yet.
- You can see 2014's accepted proposal for Scrapy here: https://gist.github.com/Curita/83851743f0db0d5b825c
General tips for submitting code samples:
- Submitting a patch to your chosen project is a requirement, though it doesn’t need to be merged nor be related with the idea you picked.
- Start by reading currently open issues in the Github issue trackers. Some issues are tagged as “easy”, those are generally good picks for beginners.
- Another good source for contributions is finishing old abandoned pull requests. Ask before to make sure about the work status, and why it was stalled.
- If you identify a self-contained and short task (less than a week of work is reasonable, and you can create an issue if there isn’t one for it) from your idea we really encourage you to start working on it, it’ll make your application look really good.
- Get familiar with project and github conventions (Here’s a general guide for contributing to Scrapy: http://doc.scrapy.org/en/master/contributing.html). For example, we’ll often ask you to “rebase” or “squash” your changes, please read git tutorials to know what those terms are if you haven’t heard of them yet.
- Make sure your pull requests have proper documentation and tests (this is something commonly missing from many stalled pull requests). All current tests should pass to get your changes merged.
- Don’t get discouraged by our feedback! We’ll probably ask you for more changes than from regular contributors to test how responsive you are and how well you implement our requests.