Google Summer of Code/Processes

This page describes processes that are typically followed during OpenStreetMap's participation in Google Summer of Code.

Roles

There are three specific roles associated with GSoC - Administrator, Mentor and Student. The expectations for each of these roles are summarised below.

Student

During the application period, students applying for GSoC with OSM are expected to:

• Discuss their project ideas on the OSM mailing lists to seek community agreement to the scope of the project that will be of most benefit to the wider community, and is of interest to the student.
• Demonstrate an appreciation of OSM and its underlying technologies by improving the map by editing their local area, at the very least showing that they understand the xml file format for OSM data.
• Apply for GSoC on the Google GSoC web site - not directly via OSM.
• Put a draft application on the Google GSoC web site as early as possible, to allow mentors to review it and ask for clarifications before the closing date (we are not keen on applications that arrive in the last hour of the application period which we are not expecting!).

Once accepted to participate in GSoC, students are expected to:

• Create an OSM Wiki page for their project with links to source code repositories, documentation etc., which should include a weekly progress update.
• Create documentation for their project describing the scope of the work, the proposed design of the software, the key milestones to achieve the project goals and a simple project plan to track progress.
• Seek the opinion of their mentor and the wider community on the proposed project design.
• Seek the opinion of their mentor on the code they are producing.
• Produce project documentation that will be of use after GSoC.
• Invite the wider OSM community to review their work and suggest areas for improvement.

Note that the student is expected to plan the project and decide on the scope of work that can realistically be achieved within the GSoC timeframe. The mentor is there to offer advice, not to manage the project - the student is the project manager.

Mentor

The GSoC mentors are responsible for the following during the application process:

• Providing advice to students that are considering applying for GSoC on what would make a good project proposal.
• Reviewing the applications as they are received, and scoring them to help reach a consensus on which applications to accept and which to reject.
• Volunteering to act as mentor for particular projects.

They are responsible for the following during the GSoC period itself:

• Advising the students on which documentation to study to help them understand the technologies required to achieve their project goals.
• Advising the students on the project management aspects of the project (project plan - milestones, timescales etc.) as students tend to have little experience in this area.
• Reviewing the project documentation produced by the student and providing constructive criticism to help the student improve.
• Recommending approaches for engagement with the wider community.
• Providing pointers to assist the student if they have difficulties with parts of their project.
• Reviewing the code produced by the student, and providing constructive criticism.
• Evaluating the student's performance both mid-way through the programme and at the end (this evaluation determines whether or not the student receives payment from Google).

Note that the mentor is not expected to:

• Specify the project scope, milestones etc. - this is the student's responsibility - the mentor advises the student.
• 'Manage' the student - the student is responsible for his/her own time management.

Administrator

The OSM GSoC administrator (and deputy) are responsible for coordinating:

• The organisation application to GSoC.
• The project ideas page.
• Recruitment of mentors.
• Review and selection of student project proposals.
• Communications between students and mentors, and the GSoC team and the wider community.
• Providing feedback to rejected students on why their projects were not selected.

Organisation application phase

Selection of administrator

OSM needs to nominate an organisation administrator and deputy administrator(s). In recent years, the OSMF Engineering Working Group has overseen the GSoC.

If more than one person wishes to be administrator, their proposal for how to deal with administration of the programme should be discussed with mentors from previous GSoC programmes to reach a consensus on who should be administrator.

The administrator should set up a wiki page on the OSM wiki relating to this year's GSoC.

Project ideas and mentor recruitment

The administrator should set up a project ideas page, and encourage members of the OSM community to propose ideas and possible mentors. Mentors are volunteers and generally self-nominated, but should be well known to the OSM community.

Submitting application

The administrator should prepare the application following the guidelines provided by Google, and have it checked by the second administrator before the application deadline. Our past applications are available on the OSM wiki and can be used for inspiration.

Student application phase

• Students should review the Project Ideas page to identify projects that they are interested in.
• They should familiarise themselves with OSM by creating an account and improving the map by making some edits in their local area.
• They should gain a basic understanding of the OSM data structure by reading the OSM Wiki (e.g. the Elements page).
• Students should seek any clarification of the meaning of the project ideas by discussing it on one of the OSM mailing lists.
• The student should draft out a project proposal (based on the project idea), and ask for views on one of the OSM mailing lists.
• They should post their draft application on the Google GSoC web site as early as possible to allow mentors to review it early and ask for any clarification before the closing date.

Interaction with potential student applicants

Potential students applicants should be encouraged to discuss their ideas on the osm-dev mailing list. It is acceptable for potential mentors to coach the applicants on the best way to present the application to improve the likelihood of it being accepted if they ask for help. Such advice can be presented as private emails to the individuals. To facilitate this, mentors should have access to the GSoC platform during the student application phase.

Generic advice should be added to the GSoC wiki page to help other potential applicants.

Assessment of applications

The potential mentors should review the applications. The assessment by mentors forms the basis for the selection of student proposals. The exact mechanism for this has varied over the years and will be communicated by the project administrator.

A private email group will be established to allow candid discussion of the applications between mentors.

Mentors are generally self nominated for specific projects. If more than one individual wishes to act as mentor for a particular project they should try to work together as joint mentors, with one allocated as the primary mentor.

Coding phase

Communications

Private student-mentor communications

Students and their mentors communicate privately using whichever means suits them.

Wiki pages

The accepted projects should be documented on the OSM wiki, with information such as:

• Project title
• Student name & contact details (e.g. OSM user ID)
• Mentor name & contact details (e.g. OSM user ID)
• Link to weekly project updates

See Category:Google Summer of Code accepted projects for past examples. In recent years, this content was added to a table on an "Accepted projects" page. Sometimes, students have also create a separate page on the OSM wiki for their GSoC project. This should be created underneath the relevant GSoC main page (e.g. Google_Summer_of_Code/2020/OSM_Widget_Creator). This page can be used to detail the following:

• Summary of the project goals.
• Project time line (originally from project proposal, but may be updated in consultation with mentor).
• Target for mid-term evaluation (i.e. what do you need to achieve to pass the mid term evaluation - to be agreed with mentor).
• Link to project design documentation
• Weekly project updates (unless published elsewhere).

It may be appropriate to have a separate wiki page for the 'completed' project - i.e. once the work is complete, information on the finished 'product' - this should be developed in parallel with the code.

OSM community updates

Each student is required to provide a weekly update of progress, saying what is going well, where they are having difficulty, and if they would like any additional help. This weekly update should be posted on a suitable public communications channel, and linked from the wiki as identified above. The mentor should make sure that the student understands this expectation.

Evaluation of students

The primary mentor should be the person who fills in the evaluations of the student, but the results of the evaluation should be discussed with other co-mentors.

If the primary mentor is not available to fill in the evaluation (e.g. on holiday) they should arrange for a secondary mentor or the administrator to fill it in on their behalf.

The Pass-Fail decision is a judgement based on the achievements of the student during the coding period. It should be based on the previously agreed timeline.

Dealing with problems

If the student or mentor is concerned about progress, or they are struggling to communicate, contact the OSM GSoC Administrators, who will help to resolve issues.

Mentor summit

Two mentors will be eligible to attend the mentor summit (usually held in California). There is a fixed budget for travel to cover both mentors. The administrator should ask which mentors would like to attend. If more than two mentors would like to attend the administrator should decide, based on the following criteria:

• Affordability (it may not be possible for two mentors to attend from abroad given the available budget).
• Previous attendance at a mentor summit (preference should be given to people who have not attended previously).
• Other factors - if it is not possible to make a clear decision based on the above, the nominees should write a short paragraph explaining to the other mentors why they should be chosen. The administrator should seek the views of the other mentors privately to reach a decision, and provide the reasoning for the decision to the whole group.