Practical information for students
When can students apply for GSoC?[edit | edit source]
12 March until 27 March (see timeline for more detailed information)
What programming language(s) should I know to participate in GSoC?[edit | edit source]
The programming language you need to know depends on which project you are interested in working with. You should be familiar with the programming language(s) used by that project.
Can I submit more than one proposal?[edit | edit source]
Yes, each student may submit up to five proposals. However, only one per student may be accepted. No more than one proposal per student will be accepted, no matter how many proposals you submit.
Can a group submit a proposal together to work on a single project?[edit | edit source]
No, only an individual may work on a given project.
Should I send proposals directly to the mentoring organizations?[edit | edit source]
No, all proposals should be submitted to the program site. Proposals submitted outside of the Google Summer of Code program site will not be considered for Google Summer of Code.
What are the eligibility requirements for participation?[edit | edit source]
- You must be at least 18 years of age
- You must currently be a full or part-time student (or have been accepted for the fall term) at an accredited university as of the student acceptance date
- You must be eligible to work in the country you will reside in during the program
- You have not already been accepted as a Student in GSoC more than once
- You must reside in a country that is not currently embargoed by the United States. See Program Rules for more information.
What forms will I need to provide?[edit | edit source]
All applicants will need to provide proof of enrollment to an accredited educational institution.
Accepted participants will need to provide a[https://developers.google.com/open-source/gsoc/help/tax-forms ppropriate tax forms.]
I graduate in the middle of the program. Can I still participate?[edit | edit source]
Yes, as long as you are accepted into or enrolled in a college or university program as of the date accepted students are announced, you are eligible to participate in the program. Students must provide proof of enrollment during the proposal period.
Do I get paid for participating in GSoC?[edit | edit source]
Yes! Google will provide a stipend to those students who successfully complete the program. More information on the stipend can [https://developers.google.com/open-source/gsoc/help/student-stipends be found here].
Will I get paid even if the organization does not use my code?[edit | edit source]
Yes, so long as the student passes his/her evaluation(s). Whether or not the project uses the produced code does not impact the student stipend.
What does a good student proposal look like?[edit | edit source]
The Student Manual has a section on "Writing a Proposal".
The best proposals are often from students who took the time to interact and discuss their ideas with the organization before submission. Be sure to include the following: detail on exactly what you're proposing, why you're proposing it, the reason you're qualified to do it, and your development methodology. It should also include details of your academic, industry, and/or open source development experience.
How much time does GSoC participation take?[edit | edit source]
You are expected to spend around 30+ hours a week working on your project during the 3 month coding period. If you already have an internship, another summer job, or plan to be gone on vacation for more than a week during that time, GSoC is not the right program for you this year.
Student proposal guidelines[edit | edit source]
A project proposal is what you will be judged upon. Write a clear proposal on what you plan to do, the scope of your project, and why we should choose you to do it. Proposals are the basis of the GSoC projects and therefore one of the most important things to do well.
Below is the application template.
Every software project should solve a problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. Include links to discussions, features, or bugs that describe the problem further if necessary.
Be short and to the point, and perhaps format it as a list. Propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the Google Summer of Code term is what counts.
Be detailed. Describe what you plan to do as a solution for the problem you defined above. Include technical details, showing that you understand the technology. Illustrate key technical elements of your proposed solution in reasonable detail.
Show that you understand the problem, have a solution, have also broken it down into manageable parts, and that you have a realistic plan on how to accomplish your goal. Here you set expectations, so don’t make promises you can’t keep. A modest, realistic and detailed timeline is better than promising the impossible.
If you have other commitments during GSoC, such as a job, vacation, exams, internship, seminars, or papers to write, disclose them here. GSoC should be treated like a full-time job, and we will expect approximately 40 hours of work per week. If you have conflicts, explain how you will work around them. If you are found to have conflicts which you did not disclose, you may be failed.
Open and clear communication is of utmost importance. Include your plans for communication in your proposal; daily if possible.You will need to initiate weekly formal communication such as a blog post on the KDE Planet or detailed email to the team mail list. Lack of communication will result in you being failed.
Provide your contact information (IRC nick, email, IM, phone) and write a few sentences about you and why you think you are the best for this job. Prior contributions to open source projects is a plus; list your commits. Name people (other developers, students, professors) who can act as a reference for you. Mention your field of study if necessary. Now is the time to join the relevant irc/telegram channels, mail lists and blog feeds. We want you to be a part of our community, not just contribute your code.
Hints[edit | edit source]
Submit your proposal early: early submissions get more attention from developers because that they have more time to read them. The more people see your proposal, the more it will be discussed.
Do not leave it all to the last minute: while it is Google that is operating the webserver, it would be wise to expect a last-minute overload on the server. So, be sure you send your application and proof of enrollment before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a lower vote because of that.
Keep it simple: Be concise and precise. Provide a clear, descriptive title. "My Project" is the worst possible title!
Know what you are talking about: Do not submit ideas that cannot be accomplished realistically or that are not related to proposed projects. If your idea is unusual, be sure to explain it
Aim wide: submit more than one proposal, in different areas. You are allowed to submit to more than one organisation as well. This will increase your chances of being chosen.
Top tips for GSOC applications - Writing your GSOC application[edit | edit source]
Here are the main tips to help you in writing your GSOC application from Apertium.
- Be realistic
- We're more likely to accept ideas which are realistic than ones which are "way out there". But if you have a "way out there" idea, don't panic! We're still interested, but we'll try to find a subset of it which is achievable in the time scale available.
- Be appropriate
- Demonstrate you have a knowledge of Apertium, how it works and the problem it has that you'd like to solve.
- Have a plan
- Three months may seem like a long time, but it isn't. Show you have a definite plan with dates and deliverables, split into weeks is probably best. Don't forget to leave time for getting familiar with the platform — this should be ideally before, or in the community bonding period — and for documentation. Anyone thinking of working on a language pair should make sure that they read about testvoc and other quality controls, and factor those in. If you know of any breaks or absences beforehand, be upfront about them and plan around them.
- Get in contact ASAP!
- We get a lot of proposals: some good, most bad. Get in contact with your potential mentor as soon as possible by sending your proposal to the mailing list, and asking for feedback. Be responsive to feedback. Refine your application based on feedback. If the mentors remember you, your chances of being picked are higher.
- Read the Ideas Page!
- If you find yourself asking 'do you have any Java/Python/Fortran/x86 assembler projects...' -- you didn't read the ideas page. Read the ideas page.
- Do the coding challenge
- Every idea will have a coding challenge to perform, this is basically a test to see if you have the required skills to do the project or if you can acquire them in a short amount of time.