Let’s make OPW better
May 25th, 2014 — pborAs many other already expressed on planet GNOME, I find Philip‘s post pretty disconcerting, especially since he mentions some of the projects I work on and that over the last years have seen many successful and rewarding contributions from OPW interns and GSOC students.
Our developer tools surely need more work to make them compelling, but that is achieved by forming a vision of how those should work, designing solutions to achieve that vision and contributing code to implement the design. Maybe Philip could blog about which amazing new patches he created for the projects he mentions or volunteer for mentoring some talented new contributor to work on those projects…
With that said, I think we should take the time consider how to make programs like OPW and GSOC even more successful and effective than what we have today. Here are a few ideas… I am not sure that all of them are good, as a matter of fact I can think of a few downsides to some of them, but I think they are at least worth discussing.
- Group projects: GSOC has a policy of 1 student : 1 project, that makes a lot of sense for administrative reasons, but I think it is pretty detrimental to the goal of involving new contributors. Working in a small group of 2 or 3 people on a project allows interns to learn to collaborate effectively, tackle more challenging problems and lighten the workload of mentors since I think many of the day to day problems can be overcome discussing within the team
- More flexible schedule and size: both GSOC and OPW have a well established cadence that also resonates with our release schedule. This has some obvious positve sides, but makes me wonder if there are negatives too… All proposed tasks must be of a reasonable size for the given period and we often have a hard time coming up with good proposals. I also wonder if we delay tackling some specific problem or idea that would benefit our users today, just because it may be a good internship project in the future
- Find a way to have more maintenance/implementation tasks: most of the tasks are “new features”, which sometimes leads to a strange inversion where we force inexperienced developers to struggle with architecture and API design while the time of the experienced developers goes into maintenance work and bugfixing. It would be great to find a way to let new contributors ramp up their experience and get familiar with the codebase and platform and at the same time have experienced developers work on advanced features without incurring in same the pitfalls over and over
- Alternative compensation: when I started contributing to gnome on my free time the main driving factors were the possibility to learn how real software worked, the possibility of making a difference creating something that other people use daily and the ability of scratching my own itches in the software I used. The original idea behind monetary compensation in GSOC was to be able to have some brilliant students work full time of free software during the summer instead of going flipping burgers and I do not think anyone can argue with the original idea, but we need to make sure we select contributors that are committed to working on gnome. How do we avoid frustrating contributors who do not get any money for their efforts? What if the reward was an internship in one of the sponsoring companies? Or some credits for the academic career? (Obviously this would require to have those organization on board with the idea)
May 25th, 2014 at 3:28 pm
Paolo, thank you for your support and your ideas!
For group projects, even with GSoC and OPW we end up with groups of interns working on the same module, which in some cases promotes working as a team. Fore example, last year the Music interns worked well together as a team. This year, we also have many modules that have several interns working on them https://mail.gnome.org/archives/foundation-list/2014-April/msg00098.html Still, with remote projects, it can be hard enough for an intern and a mentor to coordinate, let alone for a group of new interns, so it’s best if there is an individual responsibility for the interns. Group projects, which can include pair programming, for example, can work well in the academic setting, or anywhere where the contributors are in the same geographic location.
Organizing these programs is a lot of work, and it is easier if a certain type of activity happens at the same time – you answer the questions from mentors when many mentors are tuned in, the interns have a peers group, the payments have to go out at the same time. While it would be ideal to have rolling, customizable in length internships, right now we don’t have resources for it – and even Google doesn’t, even though this has been proposed to them many times.
I absolutely agree about the smaller tasks for interns who are new contributors. We already encourage those on https://wiki.gnome.org/Outreach/InfoForMentors
The idea behind GSoC and OPW is that offering financial support lets people dedicate more time to contributing to free software and building their experience in it. It compliments the other motivations people have to contribute to free software, such as the ones you had when you started out. Contributing to free software in one’s spare time often leads to jobs related to the contributions. We sometimes have people posting about the positions available at their organizations on Planet GNOME, which is a great practice. We could perhaps offer more lightweight options of promoting the positions and also reaching more people, by occasionally posting about the positions with our advisory board organizations on our social networks. The board can provide letters about contribution, which can be used to gain academic credit if the requirements match up, and can also arrange for formal volunteer experience with the Foundation. It’s something we should formalize and advertise more widely.
May 27th, 2014 at 1:34 am
My problem with SoC and OPW is more fundamental. It doesn’t attract the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. While some may see them as the crazy ones, they’re the geniuses. Because the people who are crazy enough to think they can change the world, are the ones who do. And those people don’t walk through the bureaucracy that is SoC. What you get in SoC is conformant worker bees and mercenaries, but not rebels.
That in itself is not a bad thing. It’s great that we are attracting that kind of people. What is a bad thing is that we have no way to accommodate the other kind.
And I do think most of us would have never gone through SoC had it existed when we were beginning with Free Software. I certainly wouldn’t have. Fuck mentors that are running around and judging me and my work.
May 29th, 2014 at 2:54 am
[…] you to everyone who spoke up in the last few days in support of the Outreach Program for Women. The reason we need to have this […]
[WORDPRESS HASHCASH] Snoopy failed to fetch results for the comment blog url (https://blogs.gnome.org/marina/2014/05/29/why-we-need-the-outreach-program-for-women-and-more-outreach/) with error ” and so is spam.