Google Summer of Code Recommendations for Students

From OSGeo
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

How to get in contact via mailing lists

Since OSGeo is an umbrella organisation for multiple projects, each project has their own discussion and development mailing lists.

Main OSGeo mailing lists of interest to students:

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

Also see the Mailing Lists page for project specific lists, as well as the longer list at http://lists.osgeo.org.


How to get in contact via IRC

Primary channel:

GSoC @ OSGeo inter-project discussions:

Project irc channels:

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 behaviors 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 melange, because it won't be noticed. Mentors and developers discuss ideas most in mailing lists.

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!

Application questions we'll ask you

  • All questions must be answered, no exceptions. Treat this as something between a formal job application and a scholarship application, because that's exactly what it is.
Name:

Country:

School and degree:

Email:

Phone:

OSGeo project(s):

Title:
(please include the name of the member project as part of the title, for example: "Gee Whiz Foobar 2001 for QGIS")

Describe your idea
  1. Introduction
  2. Background
  3. The idea
  4. Project plan (detailed timeline: how do you plan to spend your summer?)
  5. Future ideas / How can your idea be expanded? 

Explain how your SoC task would benefit the OSGeo member project and more generally the OSGeo Foundation as a whole:

Please provide details of general computing experience: 
 (operating systems you use on a day-to-day basis, languages you could write a program in, hardware, networking experience, etc.)

Please provide details of previous GIS experience:

Please provide details of any previous involvement with GIS programming and other software programming:

Please tell us why you are interested in GIS and open source software:

Please tell us why you are interested in working for OSGeo and the software project you have selected:

Please tell us why you are interested in your specific coding project:

Would your application contribute to your ongoing studies/degree? If so, how?

Please explain how you intend to continue being an active member of your project and/or OSGeo AFTER the summer is over:

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? (May 19 to August 18)

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

Yes, every week we expect to see a report posted to the soc@osgeo mailing list that at least answers the following questions:

  1. What did you get done this week?
  2. What do you plan on doing next week?
  3. 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. *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 in IRC. Twitchy mentors is not what we want. If you are blocked by finals, that's cool. We have all studied at some point, 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 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.

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 OSGeoofcode 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.)