Google Summer of Code Recommendations for Students

From OSGeo
Jump to navigation Jump to search

GSoC2016Logo.jpg @ OSGeo 300 127 pixel.png


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.

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.
  • 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!

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. Developers will then assist students in filling the proposal template (see below) and will prepare a small coding test (programming exercise or bug fix). See GSoC Roles and Responsibilities to understand a successfull teamwork and interplay of project, mentors and students.

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.
  • 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 GSoC 2016 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;
  • 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:

  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.

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:

GSoC @ OSGeo inter-project discussions:

Project irc channels:

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Google_Summer_of_Code_Recommendations_for_Students&oldid=105597"