[opensuse-project] Google Summer of Code Summit
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. First of all, I must say that it was a GREAT event. Very well organized and with many useful conversations and sessions. It was my first GSoC Mentors Summit, but most veterans and organizers agreed it was the best edition so far. Not a single minute felt wasted. 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. :-) The GSoC Summit follows the unconference[2] format, meaning that most sessions are not planned in advance, but decided and re-arranged by the participants themselves as the event takes place. I will try to provide my view on the sessions I attended, in no particular order. Lightning talks =============== About 2 hours of the schedule were reserved for optional 3 minutes long lightning talks about the GSoC projects. Up to 1 minute could be used to present the organization and the other 2 to present the student's work. The presentations were agile and smooth, with almost no time wasted between them. Still, looks like everybody wanted to present something and the time had to be expanded, almost duplicated, until very late at night. I tried to present the openSUSE project, emphasizing the diversity and the importance of the "subprojects" like OBS, openQA, OSEM or Portus as well as promoting our mentoring page[3]. 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. You can find the slides for all the lightning talks at [6]. 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. 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. And the last note is about future perspectives. It's important to always provide an overview on what's next for the student within the project after he/she is done with GSoC. In the short/mid/long term. Even ask the students about that during GSoC, once they are familiar enough with the project to decide where they fit. Regarding this, check the "action items" section of the full notes document linked above. Open event solutions ==================== I assumed by the title this was the presentation of some solution similar to OSEM so I decided to show up there to make sure the developers were aware of OSEM and to discuss what we could learn from each other. It was indeed a presentation about Open Event[8]. It turned to be a quite unidirectional and commercial-style presentation. The developers were aware of OSEM but were more interested in presenting their solution than in discussing about the ecosystem. Maybe is a consequence on their presentation skills, but I have to say that Open Event looks like a real powerful, complete and polished solution. It has a lot of features and configuration options, as well as a modular architecture that makes it quite flexible (although maybe harder to setup). Apart from the self-hosted option, they offer it as a service. 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. One of our GSoC projects was a redesign of the Jangouts UI. Unfortunately it was not 100% complete for the summit and I didn't have a working copy in my laptop (remember it was an unconference, so it took me by surprise). But I took the opportunity to evaluate the current UI (hopefully to be replaced soon) and I still found many interesting things. This is not the place for a full report about it (coming soon in the Jangouts ml) but, in sort, the testers pointed a lot of usability problems we were already aware (like selection and location of icons) and also pointed push-to-talk and the possibility of completely rearrange the UI as the two killer features when compared to any other similar solution... unfortunately those two features were also the most difficult to discover and understand at first sight. :-/ How to handle lot of issues =========================== I attended this section with my YaST developer hat, since we get tons of bug reports every day. The session turned to be kind of a honeypot from Lasse Schuirmann to present his project/product GitMate[9], a machine learning powered system to help with bug screening. It automatically identifies duplicates, classifies incoming issues and similar tasks. At this moment it is compatible with GitHub, GitLab and Jira. They would consider adding support for Bugzilla if some relevant organization is interested on using it. GSoC Feedback ============= This session driven by the folks at Google Open Source (the team at Google behind GSoC) was one of the many opportunities for the mentors to point to things to improve, not only about GSoC itself, but also about Google Code-In. And to be honest, after 13 editions the program seems to be quite close to perfection. I don't remember any big point mentioned here. What more should Google do? =========================== Another session by Google Open Source to find out what else they can do beyond GSoC. Recently Google Code-In was introduced, but they are still wondering which others initiatives can they introduce to help the different free software projects around the world. Some pretty obvious things were pointed, like simply providing money or free infrastructure, since free software projects has a cost beyond the hours invested in programming. I pointed that, although Summer of Code its great, we need to go beyond the "Code" part. The Open Source world needs designers, UX experts, lawyers, sysadmins... So my wish to the Google Open Source folks was some "Google Summer of Stuff-that-is-not-code"... Of course, I will leave the name to them. :-) It looked to me like it was something on their minds for some time already. Fail your students! =================== Another interesting session in which veteran mentors encouraged all organizations to be strict with the students. The main idea was: if you are not 100% sure whether your student should pass an evaluation, it's quite likely that he/she should not. We examined all the excuses that we, the mentors, usually tell ourselves to pass students that have not delivered a finished project or that are clearly not on track on the first evaluations. In short, no excuses. Being strict is better to keep the quality of the projects and of the GSoC program in general... and it's a better lesson for the students. The GSoC organizers were also there and they confirmed they have never considered organizations which fail students to be worse or better than others. They fully trust the organizations criteria and they never see a failing student like a failure of the program or the organization. Rather the opposite, as a sign of search for excellence. Organizational homes for FOSS projects ====================================== Session organized by members of the Software Freedom Conservacy[10] and similar organizations. Mainly to explain the services they offer and to research what are the needs of FOSS projects, but not many people showed up. I took the opportunity to explain them how openSUSE has organically evolved into some kind of umbrella organization for some non-operating systems like OSEM, Portus, Jangouts, etc. They were not aware of it and found it quite interesting, we should keep contact (note to self: write a mail to Brett Smith). 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. Retro arcade games in Kodi ========================== The Kodi[11] team showcased some of the upcoming gaming-related features, specially the integration with Libretto[12] to offer emulation of many platforms through the usual Kodi GUI and the integration with Archive.org to easily browse and download the ROMs with the games. More info about the whole Kodi-Game branch can be found here[13]. WebRTC ====== A kind of round table proposed by the Jitsi[14] folks, surely the organization with more representatives at the summit (five people, if I'm not mistaken). In fact, looks like Jitsi has grown a lot and they have 12 full-time paid developers working on it. They all knew Jangouts and were very positive about it, even recommending some attendees to give it a try. We discussed the scalability problems of Jitsi that leaded to the creation of Jangouts. They told me they have been working hard in the last couple of years to improve congestion control in order to allow bigger meetings. So maybe it's time to give Jitsi another try We also discussed other technical aspects and I plan to take a closer look to how Jitsi does continuous integration testing based on Chrom(e/ium). Insane proposals for GSoC ========================= A lightweight humorous section to close GSoC were organizations showed the most ridiculous applications they got. Some organizations have to deal with really insane stuff. A lot of fun. 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. Cheers. [1] https://sites.google.com/view/2017gsocmentorsummit [2] https://en.wikipedia.org/wiki/Unconference [3] https://101.opensuse.org [4] https://github.com/sils [5] https://projects.coala.io [6] https://drive.google.com/drive/folders/0B-c5jwGzSQyPMkNCYUxUXzBCLXM [7] https://docs.google.com/document/d/191ItHQfO92MxoS-IQ2dmlEQ3TcPqXGkFgzdyFXEF... [8] https://github.com/fossasia/open-event [9] https://gitmate.io [10] https://sfconservancy.org/ [11] https://kodi.tv [12] https://www.libretro.com [13] http://kodi.wiki/view/Kodi_Game [14] https://jitsi.org/ -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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
participants (2)
-
Ana Martínez
-
Ancor Gonzalez Sosa