GSoC 2020 Application Template
GSoC 2020 Application Template
Be sure to read through the GSoC 2020 Student Instructions first!
Writing your proposal
To be considered, a GSoC application must have a written proposal submitted to https://summerofcode.withgoogle.com.
If you want, you can start a wiki page to work on your proposal at
https://github.com/sympy/sympy/wiki/. If you add your proposal there, we will
help you edit it and provide feedback (though understand that we will not help
you write it). You can add your application to our list of
GSoC 2020 Current Applications. To maintain a consistent naming
scheme, title your application on the wiki:
GSoC 2020 Application <Your Name>: <Project Name>. Old applications can be found either through the links on the main
page of the wiki or by browsing through _pages.
Note that your final application must be submitted at https://summerofcode.withgoogle.com.
You should include the following information in your proposal:
Please use a succinct title that describes your proposal. Do not include the words "GSoC", "2020", or your name in the proposal title on Google's website.
You the person
Please put this information at the top of your proposal.
Your full name
University / current enrollment
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
- Any other user name 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.
You the programmer
In your project proposal let us know about your programming experience. Don't worry if you don't know SymPy or git. Many of our students start fresh. We will teach you what you need to know.
What platform do you use to code? What editor do you prefer and why?
What is your experience programming? Tell us about something you have created.
What is your experience with Python? What are your favorite features of Python that are lacking in most other common programming languages? What, in your opinion, is the most advanced Python language feature or standard library functionality that you have used?
What is your favorite feature of SymPy? Demonstrate it here with a cool example.
Have you ever used git or another version control system?
You and your project
Answer the following questions in your proposal:
What do you want to achieve?
What excites you about this project? Why did you choose it?
What qualifications do you have to implement your idea? For example, if you are implementing solvers for partial differential equations, what courses have you taken or books have you read on PDEs? Why are you suited to work on this project?
What have other people done on this idea? Has it been implemented before? (hint: it probably has) Are there any papers or blog posts about it?
How much time do you plan to invest in the project before, during, and after the Summer of Code? (we expect full time 40h/week during GSoC, but better make this explicit) If you plan to take any vacations over the summer, let us know about it here.
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 that plan on your blog.
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. 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. Copying text without citation is plagiarism and will result in your application being rejected.
You do not need to format your application as a question/answer format for the above questions, but we expect to see all of the above questions answered in your application somewhere.
In addition to the written proposal, we require every GSoC applicant to write a patch and get it pushed into the main SymPy repo. Note: even if your project will primarily deal with another repo such as SymEngine or SymPy Live, you must have at least one patch in the main SymPy repo. Patches to those other repos are encouraged in addition to the one to SymPy, if your project will deal with them.
Please note that we take your patches to SymPy into strong consideration when reviewing your proposal. This is your best opportunity to prove to us that you are capable of doing what is in your proposal.
To do this:
Set up your platform to develop with SymPy (install git, clone https://github.com/sympy/sympy.git, execute tests). Our Development workflow will walk you through setting up git and lays out our preferred way of development. Please do not make your patches through the GitHub web editor. You will need to learn how to develop your code locally and use git for your project if it is accepted, so it is best to learn now. We will happily help you with git on Gitter. We expect most students will be new to git, so this is not an issue.
Create an account at GitHub and fork SymPy (https://github.com/sympy/sympy).
Find something in SymPy that doesn't work or needs improvement and send us a git patch fixing it. If you need inspiration, feel free to fix any issue from our easy to fix issues list. Note that you may often have better luck looking for older issues, that aren't on the first page of the search results. Aside from the issues, search for
TODOin the code. You can grep from the command line with
git grep "TODO". You could also search for
XFAILtest is a test that is currently failing. See if you can fix the code to make it not fail. Search the code for
@XFAIL.). You could also play with SymPy and find something that needs fixing or that could be implemented, and do it.
The patch does not need to be related to your project to satisfy the requirement. You may wish to try to fix a bug in the code you would be working on, in order to start familiarizing yourself with it, but this is not part of the patch requirement.
Publish your patch for peer review by creating a pull request on GitHub. You must submit a patch that is successfully reviewed and merged in to be accepted. We do not consider applications without patches. This shows us that you know Python and that you are able to interact with the community. Furthermore, your patch must go through a GitHub pull request (as opposed to a patch file on an issue, for example), as this is not only the easiest way for us to review your code, but is also what we expect from a student working on a GSoC project.
Reviewers will request changes on your pull request. You should address these changes. The Travis CI will also automatically run the test suite whenever you push changes up. If there are any test failures, you should fix them before requesting a review. A pull request cannot be merged unless all the tests pass. You can run the tests yourself on your own computer (see the Development workflow).
In your application, please provide a brief summary of your contributions to SymPy so far, including unmerged work. This should be a list of pull request indicating if they are merged, closed, or still open. If you made significant contributions outside of one of your pull requests (e.g., reviewing some else's pull request), you may list that as well.
Please be patient with the reviewers. Due to GSoC, there are a lot of pull requests to review, and we may be slow to review the pull requests. Because of this, you do not have to have your request merged by the application deadline (though you should try to do it if you can!). But you do need to at least have one submitted by then. We will give priority to reviewing requests that are needed to satisfy patch requirements. It is up to you to respond to our feedback in a timely enough manner so that your patch gets merged before the acceptance deadline.