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 Contributor. The expectations for each of these roles are summarised below.

Contributor

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

• Discuss their project ideas on the OSM community forum or similar platforms 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 contributor.
• Demonstrate an appreciation of OSM and its underlying technologies by improving the map by editing their local area.
• Make some kind of contribution to the specific open source codebase they're applying to work on, and establish a connection with the potential mentors.
• Follow our instructions for applications published on the wiki page about that year's GSoC iteration, and meet any prerequisites documented there.
• 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, contributors are expected to:

• Publish regular public project updates, including an introduction of the project and a final report.
• 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 contributor 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 contributor is the project manager.

Mentor

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

• Providing advice to contributors 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 contributors on which documentation to study to help them understand the technologies required to achieve their project goals.
• Advising the contributors on the project management aspects of the project (project plan - milestones, timescales etc.) as contributors tend to have little experience in this area.
• Reviewing the project documentation produced by the contributor and providing constructive criticism to help the contributor improve.
• Recommending approaches for engagement with the wider community.
• Providing pointers to assist the contributor if they have difficulties with parts of their project.
• Reviewing the code produced by the contributor, and providing constructive criticism.
• Evaluating the contributor'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 contributor.
• 'Manage' the contributor - the contributor is responsible for their own time management.

Administrator

The OSM GSoC org admin team is responsible for coordinating:

• The organisation application to GSoC.
• The project ideas page.
• Recruitment of mentors.
• Review and selection of contributor project proposals.
• Communications between contributors and mentors, and the GSoC team and the wider community.

Organisation application phase

Selection of administrators

OSM needs to nominate organisation administrators. In recent years, the OSMF Engineering Working Group has delegated this to a small team of trusted community members.

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

Project ideas and mentor recruitment

The administrators 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 administrators should prepare the application following the guidelines provided by Google. Our past applications are available on the OSM wiki and can be used for inspiration.

Contributor application phase

• Contributors 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).
• Contributors should seek any clarification of the meaning of the project ideas by discussing it on an OSM communication channel.
• The contributor should draft out a project proposal (based on the project idea), and ask for views on one of the OSM communication channels.
• 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 contributor applicants

Potential contributor applicants should be encouraged to discuss their ideas on OSM community channels. 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 contributor 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 contributor 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 of them allocated as the primary mentor. Our goal is to have at least two mentors (primary mentor and backup mentor) assigned for each project.

Coding phase

Communications

Private contributor-mentor communications

Contributors 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
• Contributor 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, contributors 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 contributor 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. Popular choices include the community forum and user diaries. The mentor should make sure that the contributor understands this expectation.

Evaluation of contributors

The primary mentor should be the person who fills in the evaluations of the contributor, 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 an administrator to fill it in on their behalf.

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

Dealing with problems

If the contributor 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

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

• Affordability (the available budget needs to be sufficient to cover the mentor's travel costs).
• 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 administrators should seek the views of the other mentors privately to reach a decision, and provide the reasoning for the decision to the whole group.