GSoC at 52°North For Mentors

If you are interested in working as a mentor for a software project within the realm of 52°North, please contact Benjamin (b.pross @52north.org).

---

Before mentoring

Some important points to know are:

• The entire program is run online, so it is expected from you to be responsive to email and chat contacts.
• In our experience, mentoring which includes regular direct meetings with Skype, Hangouts and GoToMeeting (screen sharing!) work best. No worries, the students are more than happy to stay up late so that mentors can stick to their working hours!
• Projects must be Open Source and mentors must at least be committers for the corresponding project.
• GSoC is not a recruiting program... but you do have the chance to get to know ambitious students interested in software development.
• Include roughly 5 hrs/week for mentoring in your schedule for the mentoring period, from middle of June to middle of August in 2014 (a bit more in the end and in the evaluation phases, as it is with all projects).
• 52°North staff can support you if you have absences during the mentoring period - going on holidays is not an issue :-).
• Be aware that you just get out what you put in. 10 hours per week is not much at all when you get 40 hrs worth of work by a student (which probably reflects only 20 hours of your own work, but still!) done for you in return. The student's performance scales with the mentor's support!

Project ideas for your software projects

• Add your idea to the latest project ideas page.
• Register on the GSoC mailing list for 52°North: http://list.52north.org/mailman/listinfo/gsoc.
• Then register yourself as a mentor at melange (see below).

Selection Process

The selection process can roughly be divided into two parts:

1. getting to know the students and each mentor deciding who he wants to have for a project (and who else would be the second, third, ... in line)
2. slot filling for the whole organisation

Mentors get to know the students

• Read http://en.flossmanuals.net/GSoCMentoring/selecting-a-student
• Read the information for students to know what they are supposed to do and know already: GSoCForStudents
• During the application process: Discuss (preferably on the mailing list) project ideas with students beforehand. A student that is bad at communicating before the application deadline will most probably NOT be a great communicator during the summer.
• Give the students small tasks, such as installing the service and fixing some bugs. See also the "Student Turing Test" discussion on the mentors mailing list (only partially copied here):
  "What we do is require a patch for every student, or they are not even considered. I don't think "other evidence" is a good idea, because they can easily just take someone else's code.
  
  The real thing you should check for with the patch requirement is how smart the student is, and how dedicated they appear to be. Our official requirements are that you have to submit at least one patch.
  Many students take that requirement quite literally, and submit exactly one patch, which is often a really easy one (just adding a test or something). We usually don't accept those students. The good students submit many patches, and engage in the community.
  
  Students always make mistakes with the patch, because they are new to your code base, and quite often, new to writing code at a level of quality that most open source projects expect. This is fine, but the real trick here is to test how smart the student is by asking him/her to fix the problems. Then notice how able or unable they are in doing it. The bad students will not do a very good job. As I like to say, you can't fake intelligence.
  
  A mistake I see a lot of orgs (apparently) falling into is that you are not judging proposals. You are judging students. We accepted proposals that were not as well thought out as we would like, but
  because when we asked the student specific questions in the comments section, they elaborated and gave very specific, intelligent answers. We've rejected well written proposals because the students never even bothered to introduce themselves on our mailing list.
  
  If you are unsure about a student, ask them questions. If they give wishy-washy answers that don't really say more than the proposal did, that's a bad sign. If they give answers that have true content and
  insight in them, that's a good sign.
  
  There are also some ways that you can phrase your questions to make the students avoid giving generic answers. Asking things indirectly is one way to do this. Don't ask specifically what you want to know, but rather ask questions that lead directly to that, assuming the student really does know what you are talking about."
  Source: https://groups.google.com/forum/#!searchin/google-summer-of-code-mentors-list/turing$20test/google-summer-of-code-mentors-list/8SzvEI44OuI/qplRR2m3ZWwJ
• Join us in the IRC Channel #52north > IRC
• Remind students that you had direct contact with to actually submit a proposal via Melange!
• Create a first list of students that give you the impression that they could deliver results on the project.

Mentors evaluate proposals

• Check carefully all the *proposals*. Keep an open mind towards students that did not communicate yet, but initialize some contact righaway if the proposal looks promising.
• Have at least one mandatory *video call* (Skype, Google Hangout) to get to know each other. Feel free to invite the org admins to join for organisational questions.
• The student must (if not yet done) fulfil a specific task on the software that he will be working on over the summer - the code challenge. This task must include that the student submits a patch to the code, or that he demonstrates his capabilities to work with the code in other ways.
• All the time we are clear about the fact that students are not selected yet.
• Follow up on *references* for the student, feel free to CC org admins.
• Create a *sorted list of students for each project*. Keep in mind that we cannot put efforts into non-promising projects/students and must be careful with the generous offer the program makes. Ideally you create this list by following the process described below.
• Participate in the *ranking telco* and discuss the different project proposals with the other mentors.
• If you did not get a promising student for a project idea then please add the topic to the thesis topic and internship list - this is where we will also look for the next year's GSoC: http://52north.org/about/other-activities/student-research-topics

Rating process for the organisation

Naturally there will be a mismatch between the number of slots we want and the ones we get, as well as a difference between good proposals we receive and project ideas we have, as well as between mentor capacity and students' interests. Some projects might get many proposals, others only few, but in fact these numbers are unrelated to the number of actually good proposals. At 52°North we try to balance projects between communities but also tend towards the projects that can have the greatest impact. Most importantly, the mentor-student-matchup and individual mentor committment must be good.

After the student application phase ended, the org admins will go through all proposals and the mentors will go through their proposals (and optionally through all of them) to decide on the number of slots requested (number of minimum amazing proposals, maximum number of slots we can imagine). Mentors are invited to point out proposals they got that fall into one of these categories for all, not only "their own", projects. The maximum number of slots is absolutely limited by the number of mentors, including back-ups.

The rating process happens on Melange. Mentors are invited to check out and give one of the following ratings to all proposals.

Log in to Melange, go to Dashboard and then Proposals.

Rating scheme

• 0 = no one has read this application. If you have time and the topic is
  relevant to you, be the first!
• 1 = spam or equivalent. Don't even bother reading it.
• 2 = unacceptable as it is. It would need a lot of additional work to be considered at all.
• 3 = low quality. Potentially acceptable, but very low priority. Needs work.
• 4 = good quality. A solid application, definitely in the running.
• 5 = high quality. A sure thing, depending on overall competition and resources.

To submit a rating, just click on the respective star below a proposal.

Discuss proposals

We use private comments in Melange for proposal discussion between mentors and org admins. Students can't see these, but all mentors can. Offline or non-Melange discussions (emails, chats, ...) are of course also possible but should be reflected in a short summarizing private comment. We strongly recommend to use public comments such as for discussion with students.

The fine tuning of the (3)/4/5-star-rated projects will happen based on these discussions, optimally in a telco, and we don't want to scatter the information too much. Optionally, we might start a Trello board to be able to attach more information to the proposals and interactively sort them - feedback on the process is always appreciated!

Decide

As soon as the org admins get word you many slots we get we will have an online meeting to rank the mentor-student-project combinations (!) against each other. In case of conflicts the org admins will make the call. After we submit our slot request there is a process of handling duplicate matches (more than one organisation would accept a student) which is led by the org admins. Since it can allways happen that we loose a student from the top of the list, we rank all students wit avearage ratings >> 3.

Important: We do NOT tell the students about any of the results. Google announces the results on the website, and we are not allowed to even give a hint of our decisions to the students.

Be a mentor

1. Follow the guidelines in DOs and DON'Ts of Google Summer of Code: Mentor Edition, take a look at the Mentor Manual, or at least read the mentoring quick guide.
2. An an informal weekly report to both org admins where you describe the current state of the project on the Mentor Board on Trello.
3. Every week, check out the current state of development by evaluating the source code and running (!) the application. You should be to "take over" the project and continue development at every phase.
4. Make code changes and refactorings, collaborate practically with the students.
5. Let other mentors know what you learned in the "Tipps und Tricks" section on this page.

Registration on Google Melange

[Please let Daniel know if this works for you.]

1. Register as a mentor on melange http://www.google-melange.com (login to a Google account required).
   • Yes, this has to be done again every year.
2. Fill-in or update your profile, agree to terms, Submit.
3. Visit http://www.google-melange.com/gsoc/connection/pick/google/gsoc2015 or go via your Dashboard - Connections - Connect with organizations
4. Select "52°North ..." from the list.
5. Click submit.
   
   The org admins will get an email about your registration and can then assign you the correct role (in your case "Mentor")
   
   If you have any issues, send an email to Daniel (d.nuest @ 52north.org) containing your Melange username. The username is shown on your dashboard page at the top "You are logged in as ... [username: <YOUR_USERNAME>]"

"Tipps und Tricks"

• Have two half hour telcos each week to discuss sprints - worked very well for me. -- DanielNuest - 2014-01-27
• Use Scrum, and do it with Trello. -- DanielNuest - 2014-01-27
• ...