Google Summer of Code 2017 Mentor Summit

Google Summer of Code 2017 Mentor Summit

Each year Google hosts the "Mentor Summit" event at their headquarters, where upto 2 OSGeo delegates can attend. The tentative date for this year's summit is: 13-15 October 2017.

Selection Process

GSoC bof meeting at FOSS4G Europe, July 2017 in Paris

During FOSS4G-Europe in Paris we had a BoF [1], during which we talked about the mentor summit. More info from Google here: https://developers.google.com/open-source/gsoc/2017/mentor-oa-announcements. This is a wiki page about the discussion on who should be OSGeo delegates to participate in the 2017 summit. The juice of what was discussed in the BoF is that:

• Of the 2 OSGeo delegates, one should be an admin, the other a mentor, unless no admins or no mentors apply to go, in which case, it'll be 2 admins or 2 mentors
• Eligibility:
  • must comply with Google requirements (must be 2017 Mentors with assigned student projects or a 2017 Organization Administrator);
  • for mentors : must be mentor of an OSGeo project (at least as an OSGeo community project, if not an official OSGeo project), as you would be a delegate of the OSGeo foundation.
• The call is open to hear who is interested to go. Whoever responds must COMMIT to go, otherwise you will take away the opportunity from someone else. Deadline for expression of interest is end of July. Please appoint your names in this page.
• Selection: we agreed that we must make a (fully transparent, open) lottery. We need to find a tool that allows this. Deadline for tools proposal is by the end of July. Time is short and people need to make paperwork for VISA. Please make your proposal in this page.
• Other requirements: the selected delegates are requested to make a report after returning home from the summit.

Candidates

Signing below, you commit to go to the summit in the event of a positive outcome in the lottery

Admins

• Margherita Di Leo
• add your name here

Mentors

• Rohith Reddy
• Add your name here

Draw Time

2017-07-31 @ 14.00 UTC

Proposed tools

• RandomPicker.com
  • free for non-profit organizations
  • jmckenna has created an account for "OSGeo"
  • we can create 5 draws per day (they refer to the draws as "projects")
  • a record is kept of the draw
    • example of a test draw result, for mentors (scroll the page down, you will see that "Jane" won): https://www.randompicker.com/Project/Public/Protocol.aspx?Key=440289x33021
      • note that I have specified that these draws are private (no need for others outside OSGeo to be able to search for these results)
  • jmckenna's opinion: RandomPicker is exactly what we need
• Add here your proposed tool for lottery

OSGeo Delegates 2017

• Margherita Di Leo
• Rohith Reddy

Report from Margherita Di Leo

The GSoC Mentor Summit took place from Friday, Oct 13 to Sunday, Oct 15 in Sunnyvale, CA, USA. I joined a day earlier because on Friday we (6 people from different orgs) were asked to record some videos about GSoC participation for newcomers: mentors, students, etc. I was impressed by the video recording team, they guided us through the process of recording a professional video and let us discover how it really works behind the scenes. On Friday night the official event started with the welcome session. The event over the weekend was organized in parallel sessions on the model of an unconference. The idea is that, when you go to a conference, what you really take home after it are the casual chats that you have at the coffee breaks or at dinner with people that share your interests. So at the unconference, participants propose sessions of their interest and are not supposed to make a presentation, but rather sit together and speak. At Google Corners, they have rooms with white walls where you can write on, the rooms are small and cozy and in most of them you sit around an oval table. The only session that requires a presentation is the one of lightning talks, where you have 3 minutes sharp to introduce one or two most relevant projects. I chose not to do present anything because as an admin I don’t feel in the position of choosing a project over the others. I favoured sessions where the topic was administration, umbrella organizations and most importantly Google Code-in (GCI) because we are applying this year for the first time and this seemed a great occasion to ask other organizations and gather info. Hereinafter I made a summary of the info that I collected. All in all, it was a great experience being there. I really think it’s useful for admins to be there and exchange information. This was my third time, and most probably my last one because also other admins should have the opportunity too.

Summary about GCI

Recommendations for Orgs applying for GCI for the first time.

• Mentor commitment: Make sure mentors understand that their presence is required during the whole period of the program (7 weeks non stop: November 28th, 2017 to January 17th, 2018) and they don’t underestimate the required time commitment. They can’t just disappear during the program. They can organize shifts during sensitive days like holidays, personal matters etc.
• Mentors have 36 hours max to review a task when a student submit it, but preferably 24 hrs.
• Document task revisions, in order to be consistent in the evaluation.
• Have a few mentors to clear up the queue every day
• Encourage the students to help each other. Finalists are evaluated also on community involvement.
• Presence in IRC: is key. Kids aged 13-17 are not keen to wait for hours when they reach our org. If the IRC channel is deserted, they are gone, probably they’ll land to a more active org.
• Other communication channels: after accepted orgs are announced, in case we are included, we should probably set up a dedicated mailing list for GCI students and mentors interaction. As opposed to GSoC, there is very few private communication, if any. Students are encouraged to interact with the community and help each other, and this positive behavior is rewarded.
• It could be useful to organize workshops in school to demonstrate to kids how to participate in GCI

Preparation of tasks

• There are special tasks marked as "beginner". Each student can claim 2 beginner tasks. What usually other orgs do is to set as a beginner task "setting up the dev environment (following the guidelines in a link) and write your name in the console / terminal, then make a screenshot to demonstrate it". This should allow the student start the program and get familiar to it. The subsequent tasks of course depend on this first task. So if the student has completed the beginner task, good for him. In all other (dependent) tasks we should write that "prior completing the setting up task [link] is required in order to get this task done". So even if they don't get an additional point for completing that, they should do it anyway.
• The limitation to the 3-5 hours to complete the task is not a real constraint. Students have a minimum of 3 days to complete a task, the maximum is up to the org to decide, according to difficulty.
• Bear in mind that the students receive 1 point for each task, whether easy or difficult. However, they not always choose the easy way.
• The tasks should be described in the most objective way possible, meaning that every mentor should be able to verify that the requirements are fulfilled, even if the mentor is not familiar with that specific tool. It is important to write exactly what is expected for completing the task.
• The description of the task should be self-containing, linking to all the resources that should be consulted to complete the task. Avoid being generic, always bear in mind that the instructions are addressed to kids 13 - 17 years old. All the tasks have links to doc page on how to set up dev environment and all other requirements. Consider that the student claiming that task might be starting from zero.
• Any task can be claimed by more than one student (not at the same time), unless you remove it. But removing tasks is not very common, you only do it in particular circumstances (for example you realize that contains a mistake, is incomplete, etc). A task is open for everyone to claim it. So for example, for artworks: if a task is to design a logo, you won't remove the task after one student makes a logo. What other orgs do is for example a gallery in their wiki, with all artworks made by the students. This will also prevent them from cheating because the submissions of everyone are published there for everyone to see and refer to. From this exercise they learn to build on top on someone else's work attributing the credit.
• Some orgs suggested to phrase a beginner task like: “set up the dev environment and come back talk to us.” This encourages interaction with the community.
• A possible task is: “take any bug from the bug tracker and verify it”
• It could be useful to break large tasks into smaller tasks. Some organizations reported that GCI students managed to complete GSoC projects if split into smaller tasks. They also report that the best GCI students are perfectly capable of “difficult” tasks, they can result even brighter than GSoC students, work faster and more enthusiastically. Of course with a much larger variance.
• Evaluation should take into account not only the quantity of tasks completed but also the quality of the work produced and student interaction with the community.
• A possible beginner task (OSGeo-Live): download virtualbox and the image of OSGeo-Live, run it, open the terminal, write your name in it and make a screenshot.
• Good tasks are well defined at their core. There should be no subjectivity whatsoever in the evaluation. Even an outsider should be able to evaluate if the task can be considered successfully completed or not.
• Translations are not allowed as tasks.
• Consider that students might not be familiar with common tools like pull requests. Make sure to include comprehensive instructions if something like that is required by your task.
• A possible task is: make a 20 minutes video explaining the software xxx to your fellows GCI students.
• For some more complicated tasks might be useful to set up a container / virtual environment
• Put attention on the beginner tasks because many students will claim them. If they feel comfortable with how the tasks are presented, they are hooked and continue with our organization, otherwise can choose to continue with another org.
• How to get students work on tasks on quality assurance: make it sexy. Make task description self containing and clear.