The GNOME Montréal Summit was held a month ago now, and not only was it lots of fun, but also a very productive time. Marina held a session about the outreach in GNOME, and we spent time discussing different ways to improve welcoming and attracting people in GNOME. Let me share some of the points we raised, supplemented by my own personnal opinions, that do not reflect those of my employer, when I’ll have a job.
A warm welcome
There has been a lot of nice work done structuring and cleaning up GNOME Love page. We now have a list of people newcomers can contact if they are interested in a particular project. Feel free to add your name and project to the list, the more entry points we get, the better for them!
I tend to think there is still a bit too much content on the GNOME Love page, maybe we could use more pretty diagrams (platform overview, ways to get involved) to keep the excitement growing and to reduce the amount of text we have right now (GUI tutorials, books about GNOME, tips & tricks). Feedback appreciated!
We tend to think of contributions as patches and a certain amount of code added in a project. Howeverit’s not easy at all for newcomers to just pop in and work on a patch, especially in GNOME where most software follows strict rules (as in coding style, GObject API style, etc.). And since GNOME maintains (again, for the most part) a very high quality in its code backed by many hackers, whether they’re part of a company or independent contributors, it makes the landing of a patch even tougher.
Which is why we should encourage everyone who wants to get involved to work on small tasks, would it be fixing a string typo, rewording or marking plural forms for translation. Working on manageable changes ensures that the patches are completed and landing these patches builds confidence to work on bigger patches. Having your name in the commit log is a great reward, that encourages sticking around and digging for more.
Advertise early, advertise often
If we want to get loads of people coming toward GNOME, we should definitely talk more and spread the word about the GNOME Outreach Program for Women (GOPW) and the Google Summer of Code (GSoC) earlier.
Google doesn’t announce the program very far in advance and approved organizations are only published three weeks before the application deadline, but we should encourage students to get involved in GNOME early and keep an eye out for such announcements. Having a list of mentors who can help newcomers anytime throughout the year and having that list included on the Google Summer of Code wiki page of organizations that provide year-round informal mentorship should help attract students to GNOME.
On our side, we could definitely gather ideas and promote the programs earlier. Don’t have exact dates in head, but our KDE fellows promote the Summer of Code early March if not before. Not only will that help better spreading the word, but students might get involved earlier, and get to know the tools/community before the actual program.
Communication is key to success
We have to get better at communicating with interns, and make sure they get the help and feedback they need. We have different channels of communication in GNOME, mainly IRC and mailing lists. Both are a bit intimidating to the newcomer (I still proceed with extreme care when I use them), so it would be good to have a short tutorial about the main mailing lists around, how to connect on IRC and what to expect out of it.
Always two there are, no more, no less
In order to increase the chances of success for the interns, we need good mentors. Most people underestimate what it takes to be a good mentor: being nice, supportive, competent, enthusiastic. You have to remember you’re helping someone to land in the big GNOME land without too much hassle, so consider it carefully. I encourage you to read this very informative blog post if you’re thinking about mentoring a student.
The Summer of Code administrators at GNOME could perhaps keep an eye on mentors as well as students, not with weekly reports but just by poking them from time to time and making sure everything is going well.
Show me the way
To help students set up their workflow, it would be great to have full-length screen-casts demonstrating how to fix a bug in GNOME, starting on the Bugzilla page and finishing on the same page when attaching the final patch. This means going through cloning the module with Git, using grep to find the faulty line, editing the code, using Git to look at the diff and format the final patch. All this in one video would really help connect the parts and suggest a way to work for students.
GNOME Love bug drive
Please consider attaching the gnome-love keyword when you file or triage a bug that is easy to fix. A selection of current GNOME Love bugs is essential to help newcomers figure out how they can start contributing.
Good GNOME Love bugs are trivial or straight forward bugs that everyone agrees on, e.g. paper cut bugs or corner cases. It’s helpful to specify the file or files that will need to be modified and any reference code that does something similar in the bug. Even most trivial bugs are suitable candidates, because in the end, fixing a GNOME Love bug is as much about learning the process, as about the fix itself!
If you want to help us gather more people around GNOME and help them find their spot in our community, make sure to suscribe to the outreach-list mailing list.
Thanks for reading!
And thanks to Marina and Karen for reviewing this post!