Google Summer of Code 2017 Mentor Summit

From OSGeo
Jump to navigation Jump to search

GSoC2016Logo.jpg @ Osgeo-logo.png

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

Mentors

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
    • jmckenna's opinion: RandomPicker is exactly what we need
  • Add here your proposed tool for lottery

OSGeo Delegates 2017

Report from Margherita Di Leo

The GSoC Mentor Summit took place from Friday, Oct 13 to Sunday, Oct 15 in Sunnyvale, CA, USA. This year it gathered nearly 350 participants from all over the world. Participants include GSoC admins and mentors, 2 for each organization participating in GSoC for the current year.

I joined a day earlier because on Friday we (6 people from different orgs) were asked to record some videos for newcomers about GSoC participation: how to be a mentors, how to participate as a 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, 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.

  • Timetable where participants put a post-it with the name of the session they want to organize.

  • Stickers brought by participants from their orgs. OSGeo-Live is here

  • Ribbons to attach to your badge

  • A favorite: the Chocolate table. Participants bring chocolate from all over the world

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.

Report from Rohith Reddy

The GSoC Mentor summit was held in the Sunnyvale Campus of Google between October 13-15 2017. The mentor summit is an event hosted by Google which gathers all the mentors and the admins of organisations participating in GSoC. The format of the summit was unconference which was very interesting. Where, instead of passive listening, we were allowed to participate and discuss about the topic. I was a former GSoC student in 2016 and a mentor in 2017. This was my first mentor summit and yes, I was very excited!

  • The ID: A pass to the Google Summit attendees

  • The Schedule: The post-it if you want scheduler

  • The Chocolate Table: Chocolaty bliss at the Google factory

  • Together: All the mentors and the admins smiling :)


Day 1

The summit started with an introductory session on day 1. We were asked to introduce ourselves with just 4 words that would describe us.

Day 2

There were parallel sessions and lightning talks on day 2. The lightning talks were meant to showcase the best student’s work in the organisation within 3 minutes. I couldn’t give a lightning talk as I am a mentor only for pgRouting and couldn’t decide which was the best work in the organisation. I would like to suggest that in the coming year, after the GSoc final evaluations, the mentors and the org admins should have a discussion to decide the best work in the organisation so that it can be showcased in the lightning talks of the Mentor Summit. I attended Grading Criteria for Proposals session on day 2. We discussed about the assessment of proposals, ranking proposals prior to selections and also about the steps taken to properly assess a proposal.

Summary of the discussion

  • If the organisation doesn’t have such criteria, they should come together and set up some criteria for grading students.
  • The organisation could probably have a scoring system that students can see in advance to know what the key elements the organisation is looking for. This would make the process more transparent, so students know what makes a good proposal.
  • The subjective judgement of the proposal should however be private and not enclosed until the results are announced.
  • What makes a good proposal?
  1. Prior contribution (patch) or proof of concept.
  2. Successful interaction with multiple mentors (through any channel that is used during the project later on).
  3. Openness to requests for changes; for example, young or female mentors have to be respected by a student.
  4. Good behavior, conduct and honesty.
  5. Clear goals, realistic timeline, alternative goals if project goes better/worse than planned.

Day 3

There were parallel sessions followed by a closing ceremony on the last day. I attended a Fail your Students session as I failed a student in GSoC 2017 which was a very hard decision to make and I also wanted to share my experience with the other mentors and admins. Mentors and admins also have shared their experiences of failing students and why they had to do it.

Summary of the discussion

  • Before taking the decision of failing a student, the mentors and the org admins should first decide whether the approach taken, failed in helping the student.
  • Even after failing a student in GSoC. If, the student is still interested to contribute the mentors and admins should help them learn from their mistakes .
  • Weekly meetings with all the students of the organisation where they talk about the progress in their work so that the mentors and the admins have a more informative approach to monitoring the students.
  • If the student is not performing well and he agrees upon this fact, it is better asking to withdraw from the program.
  • Failing students also indicates that the expected quality of work has increased which also improves the standard of the program.

The mentor summit is a great platform to meet a lot of open source developers, discuss and share ideas. I had a great experience in meeting a lot of people around the world and learned a lot from them. I would like to thank Google for hosting such a great event every year and also OSGeo for choosing me to represent the organisation at the summit.

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