Google Summer of Code/Processes

From OpenStreetMap Wiki
Jump to: navigation, search

Processes to be Followed during OSM 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., and 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.
  • Post a weekly project update to the osm_gsoc mailing list (of current students and mentors), which is an opportunity to ask for help or guidance from a smaller community.
  • 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 their 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.

Application Phase

Organisation Application

Selection of Administrator

OSM needs to nominate an organisation administrator and a deputy administrator. The normal way of selection is self nomination by someone who feels that they have the time and inclination to fulfil the role.

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.

Student Applications

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

Project Ideas

The administrator should set up a project ideas page, and encourage members of the OSM community to propose ideas and possible mentors.

Submitting Application

The administrator should prepare the application following the guidelines provided by Google, and have it checked by the second administator before the application deadline.

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.

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

Assessment of Applications

Selection of Mentors

The administrator should ask the OSM community for volunteer mentors - the volunteer mentors choose which applications should be accepted on behalf of OSM.

Mentors are generally self-nominated, but should be known to the OSM community.


Assessment of Applications

The potential mentors should review the applications and put them in order of preference, taking into account their personal preference for projects, the benefit it will provide to OSM, and any generic preference guidelines proposed by the administrator. Their first choice is given a score of 1, second 2 etc.

The projects should be ranked for each of the following categories separately, and summed to give a total score for each project from each mentor:

  • Value of project proposal to OSM.
  • The mentor's personal interest in the project.
  • The demonstration of knowledge of relevant OSM and other technologies by the student.

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

The administrator should summarise the overall preference order by adding together the scores given by all mentors. A discussion should be held by email or other means between the mentors to reach a consensus on the order of preference of all of the applications. The administrator then updates the scores on the google Melange application to show the agreed order of preference for the applications.

Allocation of Mentors to Projects

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. If they have very different views on how the project should be progressed the student should be allowed to take the advice of whichever mentor they prefer - ie the student selects which is the primary mentor.

Coding Phase

Communications

Private Student-Mentor Communications

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

Wiki Pages

Each student should create a 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/2012/OSM_Widget_Creator). This page should detail the following as a minimum:

  • Project Title
  • Student Name & Contact Details (e.g. OSM User ID)
  • Mentor Name & Contact Details (e.g. OSM User ID)
  • 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 (e.g. 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.

It may be appropriate to have a separate Wiki Page for the 'completed' project - ie 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 to the osm-dev mailing list, and included in their wiki page 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 agree 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 in the first half of the GSoC period - it should be based on the previously agreed target for the mid-term evaluation.

Dealing with Problems

If the student or mentor is concerned about progress, or they are struggling to communicate, contact the OSM GSoC Administrators (Graham Jones and Ian Dees for 2012), who will help to resolve issues.

Mentor Summit

Two mentors will be eligible to attend the mentor summit 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 outside of the USA 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.