Difference between revisions of "Google Summer of Code Recommendations for Students"

Back to the main OSGeo Google Summer of Code 2018 wiki page.
Check out the Ideas web page or propose your own!

How to get in contact with your potential mentors

Since OSGeo is an umbrella organisation for multiple project communities, each community has their own discussion and development Mailing Lists.

OSGeo mailing lists of interest for GSoC students:

Please start here, when contacting us for the first time with questions about Google Summer of Code.

OSGeo SoC Mentors and Students - soc@lists.osgeo.org (http://lists.osgeo.org/mailman/listinfo/soc): subscribe right away to this mailing list, and introduce yourself and your idea.
OSGeo Wide Discussion List - discuss@lists.osgeo.org (http://lists.osgeo.org/mailman/listinfo/discuss)
The dedicated dev mailing list of the software you intend to develop for (Browse http://lists.osgeo.org)

To contact OSGeo's GSoC admin team directly (only for private matters that can't be shared in SoC ML):
- send an email to gsoc-admin@osgeo.org

How to increase your chances of being selected

If you put yourself in the shoes of the mentor that should select the student, you'll immediately realize that there are some behaviours that are usually rewarded. Here's some examples.

Be proactive

Mentors are more likely to select students that openly discuss the existing ideas and / or propose their own. It is a bad idea to just submit your idea only in the Google web site without discussing it, because it won't be noticed. Mentors and developers discuss ideas mostly in mailing lists.
It is a bad idea just listing your programming skills and waiting for the mentors to guide you towards next steps. Mentors reward students that show genuine interest in the projects they are willing to develop, propose improvements on their own and make pertinent questions. Remember that it is up to you, and not to the mentor, decide the software you want to work on and the idea to develop. It is not the mentor's job to do that for you.

Discuss your idea in public channels

Even if you have had some contact with a potential mentor, remember that the proposals discussion must happen in public channels, as it is always the case in open source communities.
It is a good idea to engage the individual dev lists and find a community that you are interested in working with and start building a relationship with that community. It is the community that decides which of the candidates they want to back, based on the value of the project, and whether or not they think the student will be successful.

Demonstrate your skills

Consider that mentors are being contacted by several students that apply for the same project. A way to show that you are the best candidate, is to demonstrate that you are familiar with the software and you can code. How? Browse the bug tracker, fix some bugs and propose your patch in mailing list, and/or ask mentors to challenge you! Moreover, bug fixes are a great way to get familiar with the code.

Demonstrate your intention to stay

Students that are likely to disappear after GSoC are less likely to be selected. This is because there is no point in developing something that won't be maintained. And moreover, one scope of GSoC is to bring new developers to the community.

RTFM

Read the relevant information about GSoC in the wiki / web pages before asking. Most FAQs have been answered already!

OSGeo Wiki pages related to GSoC can be browsed from Category:Google Summer of Code.
Full documentation about GSoC on official website.
FAQ from GSoC web site.
Google Summer of Code program rules.
The student's manual.
If you are new to OSGeo, take the time to familiarize with the Open Source Geospatial Foundation
Here is a presentation
Videos playlist

Application instructions

We welcome students to contact relevant developer communities within OSGeo umbrella before submitting their application into GSoC official website. If in doubt for which project(s) to contact, send the mail to both soc and discuss mailing lists.

We recommend browsing past years' ideas pages, to look for ready-to-use projects, and to get an idea of the expected amount of work for a valid GSoC proposal. Read here how to write a nice proposals. Remember to use the template below.

Developers will then give feedback and prepare a small coding test (programming exercise or bug fix). See GSoC Roles and Responsibilities to understand a successful teamwork and interplay of project, mentors and students.

As a general remark, we know that late submissions are not our best shot, as we usually find them incomplete, so be aware that the sooner you submit your proposals, the better chances you have to adjust them to mentors' requirements, and in the end, better chances to be selected.

If you submit your proposal as "final", mentors cannot access it until deadline. So, unless you also share the google docs as public, we don't have a way to give you feedback and we will be evaluating your final proposal as it is, so you have less chances, or none at all if your proposals hasn't been discussed anywhere in public channels.

When you share your proposal, always allow comments! If you share it in view only, mentors can't give you feedback.

Remember that GSoC is a highly competitive program, we prioritize quality over quantity, this means that we only accept excellent proposals. Submitting a sloppy proposal it's just a useless waste of time for you and for mentors.

Template

1. Contact details

Name and surname:
Nickname:
Country:
Email:
Phone (we will not call you, unless you will become unreachable by email/IM for more than a week without warning):
Public repository/ies:
Personal blog (optional):
Twitter/Identica/LinkedIn/others:

2. Your idea

OSGeo or guest software:
Title: (please include the name of the member project as part of the title, for example: "Gee Whiz Foobar 2001 for QGIS")
Brief description of the idea. e.g. "My project will focus on xxx".
The state of the software BEFORE your GSoC. For example, if you want to make a GUI, you can say: "In the software XYZ, when I want to use the tool xxx, I have to manually edit the file yyy. "
The addition that your project will bring to the software. In the same example: "With the GUI that I intend to create, it will be possible to use the tool xxx via graphical user interface".
Future developments. How can your project be expanded or maintained after GSoC is over.

3. Timeline

Now split your project idea in smaller tasks. Quantify the time you think each task needs. Finally, draw a detailed project plan (timeline) including the dates covering all period of GSoC. Don’t forget to include also the days in which you don’t plan to code, because of exams, holidays etc.
Note that by the start of the official coding period, students should be ready to start coding right away. Activities such as: initial research, set up working environment, choose tools to be used in the project, set up repository, etc must be carried out during bonding period. In your timeline, please add also activities that you will be carry out during the bonding period.
Do you understand this is a serious commitment, equivalent to a full-time paid summer internship or summer job?
Do you have any known time conflicts during the official coding period?

4. Studies

What is your School and degree?
Would your application contribute to your ongoing studies/degree? If so, how?

5. Programming and GIS

Computing experience: operating systems you use on a daily basis, known programming languages, hardware, ecc.
GIS experience as a user:
GIS programming and other software programming:

6. GSoC participation

Have you participated to GSoC before?
How many times, which year, which project?
Have you applied but were not selected? When?
Have you submitted/will you submit another proposal for this year's GSoC to a different org?

What to expect after application

Now that you have submitted your application, it's time for you to set up your development environment and get familiar with the code of the software you want to develop for. Ask the developers to test you with a small coding task, or browse the bug tracker and submit a patch for a bug.

Bonding period

Bonding period does not mean relax. During bonding period, you are supposed to do all preparation in order to be able to start coding immediately the first week of actual coding period. These activities entail:

set up your dev environment: compile the source code, etc;
getting familiar with the source code, the dev documentation, programming manual and all the material that your mentors suggest;
start coding for bug fixes not necessarily related to your project;
scratching and pseudocoding your project;
set up your repository, familiarize with version control systems such as git / svn etc;
set up your wiki page, where you will describe your project and keep track of your weekly progresses;
get in touch with the community: introduce yourself in soc and dev mailing list, introduce your project and receive feedback.

What to expect during the summer

Be prepared to be in constant communication with your mentors and project

You and your mentors will decide on the specifics, but we will expect you and your mentor to communicate *a lot*. Part of the idea of SoC is to integrate you into the developer community, so you should get involved with them from the start. The more you communicate the easier it will be. Don't be afraid that the mentors will request your phone number. It is only to make sure that we can reach you in case of problems, like making sure you get paid.

University exams and semester terms vary widely, if we know in advance that you need a week off to study, or that you've already scheduled a short vacation to somewhere off the grid, that's fine and won't count against you. But you need to communicate this up front so we can make a plan to work around it.

Weekly reports

Every week, by Sunday, we expect to see a report posted to the soc@osgeo and the developer mailing list of your project, that at least answers the following questions:

What did you get done this week?
What do you plan on doing next week?
Are you blocked on anything?

These questions BTW are the same as are used in real-work, when developing with the Scrum development process.

If you want, feel free to write *more*. But three sentences is the bare minimum.

Please explicitly mention your project in the subject and in the introduction to the e-mail.

IT IS VERY IMPORTANT THAT YOU SEND YOUR PROGRESS REPORTS ON TIME, if you don't send this email your mentors will start to get twitchy, and *especially* if they don't get any responses to their emails / don't see you on IRC. Twitchy mentors is not what we want. If you are blocked by finals, that's OK. Just tell us about it up front, be honest, and we'll work around it. If you don't know how to proceed and your mentor isn't answering, *definitely* tell about it. The SoC project admins will always be available. Basically the point is that you open up the communication channels, and keep them open. That way you will have a super summer, and get paid ;)

During past years this weekly report proved to be very popular among the students and mentors alike, so we will keep it up.

Code repository and documentation

Publishing your progress online and publicly is a GSoC requirement. Therefore, all students have to decide, before GSoC coding period starts, where to publish the code they will write. We ask students to give the link to the public repository in the first weekly report.

The possibilities are:

get a sandbox in your software project's repository (your mentor will tell you how to get write access)
work on a branch of the main code repository (for centralized versioning systems like SVN)
work on a fork of the code repository (for DCVS like Mercurial and Git)
work on an independent codebase (if you are developing a plugin or some other extra functionality that is not yet part of main codebase)

Your mentor is the best guide regarding this choice. Please discuss it as soon as possible, and learn how to use the related version control tool well before GSoC coding starts.

Documentation of your code is important! Don't leave all documentation writing to the last weeks of GSoC. It makes sense to outline it at the beginning of coding period, then refine it while you code. It is an important support to coding, as it is a mirror of the overall plan for the summer, and an essential source of information for who will use your code.

Wiki page and blogs

In addition to weekly reports we require you to maintain a wiki or blog page for your project. You should store your weekly reports there and add other information, like how to compile and test your program. If applicable add screenshots and other nice info.

Wiki and/or blog space can and will be provided by OSGeo if your project doesn't have anything already set up for this. Alternatives may be code repositories with wiki/blog functionality like GitHub, GitLab or Bitbucket.

We plan to link all of the students' blogs to the OSGeo Planet blog aggregator for maximum community exposure and hopefully early feedback from the experts who read it, which may save you a lot of time and trouble if, for example, some obscure wheel has already been invented by another partner project.

Final reports from those blogs and wiki pages will be collected into a OSGeo-of-code posting about what everyone did during the summer, ensuring you long lasting fame and fortune. (Or failing that, a bit of public press, a bit of cash from Google, and a lot of gratitude and kudos from us, your peers.)

How to get in contact via IRC

Primary channel:

#osgeo on freenode.net (connect directly in your browser)

GSoC @ OSGeo inter-project discussions:

#osgeo-soc on freenode.net (connect directly in your browser)

Project irc channels:

#gdal on freenode.net (connect directly in your browser)
#geoserver on freenode.net (connect directly in your browser)
#geotools on freenode.net (connect directly in your browser)
#grass on freenode.net (connect directly in your browser)
#gvsig on freenode.net (connect directly in your browser)
#mapguide on freenode.net (connect directly in your browser)
#mapnik on freenode.net (connect directly in your browser)
#mapserver on freenode.net (connect directly in your browser)
#openlayers on freenode.net (connect directly in your browser)
#opticks on freenode.net (connect directly in your browser)
#osgeolive on freenode.net (connect directly in your browser)
#ossimplanet on freenode.net (connect directly in your browser)
#ossimplanet on freenode.net (connect directly in your browser)
https://gitter.im/pgRouting/pgrouting
#postgis on freenode.net (connect directly in your browser)
#qgis on freenode.net (connect directly in your browser)
#udig on freenode.net (connect directly in your browser)
#geonode on freenode.net (connect directly in your browser)

@@ Line 100: / Line 100: @@
 ==== 3. Timeline ====
 * Now split your project idea in smaller tasks. Quantify the time you think each task needs. Finally, draw a detailed project plan (timeline) including the dates covering all period of GSoC. Don’t forget to include also the days in which you don’t plan to code, because of exams, holidays etc.
+* Note that by the start of the official coding period, students should be ready to start coding right away. Activities such as: initial research, set up working environment, choose tools to be used in the project, set up repository, etc must be carried out during bonding period. In your timeline, please add also activities that you will be carry out during the bonding period.
 * Do you understand this is a serious commitment, equivalent to a full-time paid summer internship or summer job?
 * Do you have any known time conflicts during the official coding period?
 ==== 4. Studies ====