2017-12-12 8:13 GMT+01:00 Ancor Gonzalez Sosa <ancor@suse.de>:
Last October I was honored to represent openSUSE in the Google Summer of Code Mentors Summit[1]. With a huge delay (sorry, but real life got in the way), here is my event report.
It was kind of fun to incidentally sit in the first dinner next to another mentor just to find out she was Bubli, one of my predecessors at the YaST team, and to find we were not only connected by the past, but also in the present since she works with another developer from my island who ended up in Bubli's company through a Rails Girls workshop that I mentored in Gran Canaria (together with my brother and also current YaST developer) some years ago. Looks like the six degrees of separation theory can be reduced to two in the free software world. :-)
3.5 according to Facebook ;) https://research.fb.com/three-and-a-half-degrees-of-separation
Lasse Schuirmann[4] also presented the Coala mentoring page[5] which a similar philosophy to ours. I grabbed him in the bus after the event and we discussed about the possibility of joining efforts in the technical side of things of both mentoring pages. Something to keep in mind in the mid term.
He already opened an issue in our mentoring page some time ago, but basically he wanted that we closed our project and joined his project: https://github.com/openSUSE/mentoring/issues/75 Too be honest, mentoring is such a simple project that I think that maintaining it doesn't require that much effort. And keeping it separately allow us to customise it as we want/need.
Retaining students as long time contributors ============================================
Very interesting session. Check at [7] the full notes taken by the moderator. My own notes follow.
The most important take away: take into account that students usually don't stick around the project right after GSoC, they rather return after some time. So keep contact at a "personal" level not related to the project development itself (social networks, mail, etc.).
Another important thing that we all know but we have to reinforce. People don't get hooked only by the technical challenge, but rather by the fellowship feeling. The whole experience should be personally rewarding and there are two very easy steps for that: provide recognition and SAY THANKS. Loud and often. Reward them with thinks that means recognition and responsibility, like committer access to the repo. I came with the idea of doing some kind of Alumni initiative and turns out some organizations are already trying something similar.
Interesting thoughts! What do you exactly mean with the Alumni initiative?
We also discussed how to select students that are more likely to stay. In short, the students skills is the less important criterion in this regard. Look for students that feel identified with the mission of the project and ask as many personal questions as needed to find out that. On the other hand, experience says that choosing younger students work better in terms of long relationships, even if they are less skilled and have less chances of succeeding in GSoC. Youngest students tend to stay even if they fail and don't get all the money.
Choosing students because of their age, does seems to me like an objective reason and it is totally discriminatory.
UX round robin ==============
The idea of this session was to use another attendee as "guinea pig" exposing him/her to the UI of our tool almost with no guidance or explanation and observing the situation, followed by a brief explanation to show them features they failed to discover (if any) and get feedback about why that happened. It was done in a round robin fashion with developers and guinea pigs rotating and changing their roles.
That's sound really cool
How to manage project spam ==========================
I attended this session because we always get several proposals that looks like a clear copy&paste from some generic template or that comes from students we have not ever heard about (students are encouraged to contact the community before sending a proposal document). But I found out we are far from having a spam problem.
Looks like many organizations receives more than a hundred of such spam proposals. The most common solution seems to be to establish two lines of defense, with a group of people doing some screening just to discard spam, without really comparing the acceptable proposals to each other, and a second line of real evaluation do decide which proposals to pick or which students to contact. No better solution was presented and I hope we will never have such problem.
I remember reading one proposal like that this year, but it was only one and after 2 minutes reading I had already realised of it. So I also think it is not an issue.
That's it =========
That's mainly all. Feel free to ask any question about the event or any of the sessions or to open the discussion about how to continue any of the initiatives or relationships bootstrapped during the event.
Thanks a lot for the detailed report! ;) Ana -- Ana María Martínez Gómez http://anamaria.martinezgomez.name -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org