GSoC: Student Application Template
When you submit an application to GSoC, it will be in a Google Docs format and an application should be concise and we suggest not exceeding ~5 pages.
We also expect the final application to be hosted on our wiki. Please keep this in mind if you plan to use the fancier formatting features of Google Docs. You can do this after you have finalized the version on the GSoC website but please do it ASAP after.
Any code you want to include should be in a gist but we recommend not writing empty pseudo code or just documentation strings.
You should include a lot of the following information in your application. However, we should suggest you use your own judgement, remove sections that might not be relevant or add sections that are relevant to the project but are not listed.
Please use a succinct title that describes your proposal. Add [SunPy] to the start and to the upload on the GSoC website, it lets us filter during the review process.
Do not include the words "GSoC", "<Year>", or your name in the proposal title.
Please put this information at the top of your proposal.
-
Your full name
-
University / current enrollment
-
Time Zone
-
Short bio / overview of your background
-
How can we contact you (email, GitHub username, etc)?
This information will help us associate all of your various usernames with you.
- GitHub username
- Element.io username
- Any other username you want us to know about
Also, please use your full real name in your GSoC portal profile, so that it appears in the proposal list.
We don't need your phone number, address, date of birth or any other personal info.
-
Have you previously participated successfully in GSoC? When? With which project?
-
Are you also applying to other projects?
Not applying to other projects does not give you a higher chance of selection for SunPy, we would like to know.
-
Are you eligible to receive payments from Google?
-
How much time do you plan to invest in the project before, during, and after the Summer of Code?
We expect the full time commitment of ~18h per week during GSoC. This will vary depending on the size of the project (175 vs 350 hours) and the 12 to 22 weeks that is now allowed. You need to discuss this with the mentors. If you plan to take any vacations over the summer or if you have exams or any other commitments (like an internship), let us know about it here.
In your project proposal let us know about your programming experience.
Don't worry if you don't know much about sunpy or git/GitHub.
Many of our students start fresh on these topics and we will teach you what you need to know.
-
What is your experience with programming?
-
What is your experience with Python?
If you have Python projects or good Python code example, you should link it here. It will be good for us to see the level of Python experience you have.
-
What is your experience with open source software?
-
Have you ever used git or another version control system?
-
What are your contributions to the SunPy Project so far?
It should be a brief summary (with links) of pull requests including un-merged work. Pick what you think are your best pull requests.
-
What do you want to achieve? What excites you about this project? Why did you choose it?
-
Why are you suited to work on this project?
-
What have other people done on this idea?
It is most likely that someone has implemented (in some form) before. Are there any papers or blog posts about it? What about open issues or non-merged (open or closed) pull requests?
-
How do you plan to implement the project?
What parts of
sunpyneed changing and in what way? What will you add? What could be stumbling blocks of the project? Will you need to make changes to upstream packages? Please try not to include documentation strings for functions or pseudo code unless it is detailed. You can put these into gists and link to them in the application. -
If it involves any API changes, how does it affect the user?
Does it improve on the current API? If so, how?
-
Will you require any software packages that are not already a requirement?
If the answer is no, you can skip this. Please do not add redundant information into the application.
If the answer is yes, what ones and why? We need to be given a good reason to add extra requirements to any package.
-
Please provide a schedule of how this time will be spent on sub-tasks of the project over the period of the summer.
While this is only preliminary, we will use it to help monitor your progress throughout the program. Also understand that during the project you will issue weekly progress reports against the plan on your blog. Try to avoid using a table, it can cause issues when/if you move between Google Docs and the wiki (if you use markdown).
-
In planning your project, it is good to note where along the way you could formulate a pull request.
These would be points where you can have a self contained and well documented and tested piece of functionality. Doing this at several points during the summer helps to keep branch merges reasonable and code reviews manageable. A big code dump at the end of the summer will likely be hard to review and merge before the project deadline.
-
Please do not verbatim copy text from the ideas page, or from other people's discussions about your project, but rewrite it in your own words.
If you include any significant text or code from another source in your application, it must be accompanied with a proper citation. However, we strongly suggest you not just copy and paste large pieces of text and then add a reference, this is not ok. All papers or references that you use or plan to use must also be cited. Put all this in a "References" section at the bottom of your application.
Below is a blank template of a timeline you can try to use to fill in for your GSoC application. You are free to use another or a different style but we want this level of breakdown, either week by week or two weeks at most. You should tailor the timeline as as it suits you and the project you are working on.
The timetable dates and the format depends on GSoC, these change year on year. So you will update it yourself.
- Point X
- Point X
- Point X
- Point X
- Point X
- Point X
- Point X
- Point X
- Point X
