Joel Maher: Hacking on a defined length contribution program

Пятница, 02 Октября 2015 г. 21:18 + в цитатник

Contribution takes many forms where each person has different reasons to contribute or help people contribute. One problem we saw a need to fix was when a new contributor came to Mozilla and picked up a “good first bug”, then upon completion was left not knowing what to do next and picking up other random bugs. The essential problem is that we had no clear path defined for someone to start making more substantial improvements to our projects. This can easily lead toward no clear mentorship as well as a lot of wasted time setting up and learning new things. In response to this, we decided to launch the Summer of Contribution program.

Back in May we announced two projects to pilot this new program: perfherder and developer experience. In the announcement we asked that interested hackers commit to dedicating 5-10 hours/week for 8 weeks to one of these projects. In return, we would act as a dedicated mentor and do our best to ensure success.

I want to outline how the program was structured, what worked well, and what we want to do differently next time.

Program Structure

The program worked well enough, with some improvising, here is what we started with:

we created a set of bugs that would be good to get new contributors started and working for a few weeks
anybody could express interest via email/irc, we envisioned taking 2-3 participants based on what we thought we could handle as mentors.

That was it, we improvised a little by doing:

accepting more than 2-3 people to start (4-6)- we had a problem saying no
folks got ramped up and just kept working (there was no official start date)
blogging about who was involved and what they would be doing (intro to the perfherder team, intro to the dx team)
setting up communication channels with contributors like etherpad, email, wunderlist, bugzilla, irc
setting up regular meetings with contributors
picking an end date
summarizing the program (wlach‘s perfherder post, jmaher’s dx post)

What worked well

A lot worked very well, specifically advertising by blog post and newsgroup post and then setting the expectation of a longer contribution cycle rather than a couple weeks. Both :wlach and myself have had a good history of onboarding contributors, and feel that being patient, responding quickly, communicating effectively and regularly, and treating contributors as team members goes a long way. Onboarding is easier if you spend the time to create docs for setup (we have the ateam bootcamp). Without mentors being ready to onboard, there is no chance for making a program like this work.

Setting aside a pile of bugs to work on was successful. The first contribution is hard as there is so much time required for setup, so many tools and terms to get familiar with, and a lot of process to learn. After the first bug is completed, what comes next? Assuming it was enjoyable, one of two paths usually take place:

Ask what is next to the person that reviewed your code or was nice to you on IRC
Find another bug and ask to work on it

Both of these are OK models, but there is a trap where you could end up with a bug that is hard to fix, not well defined, outdated/irrelevant, or requires a lot of new learning/setup. This trap is something to avoid where we can build on the experience of the first bug and work on the same feature but on a bug that is a bit more challenging.

A few more thoughts on the predefined set of bugs to get started:

These should not be easily discoverable as “good first bugs“, because we want people who are committed to this program to work on them, rather than people just looking for an easy way to get involved.

They should all have a tracking bug, tag, or other method for easily seeing the entire pool of bugs

All bugs should be important to have fixed, but they are not urgent- think about “we would like to fix this later this quarter or next quarter”. If we do not have some form of urgency around getting the bugs fixed, our eagerness to help out in mentoring and reviewing will be low. A lot of times while working on a feature there are followup bugs, those are good candidates!

There should be an equal amount (5-10) of starter bugs, next bugs, and other bugs

Keep in mind this is a starter list, imagine 2-3 contributors hacking on this for a month, they will be able to complete them all.

This list can grow as the project continues

Another thing that worked is we tried to work in public channels (irc, bugzilla) as much as possible, instead of always private messaging or communicating by email. Also communicating to other team members and users of the tools that there are new team members for the next few months. This really helped the contributors see the value of the work they are doing while introducing them to a larger software team.

Blog posts were successful at communicating and helping keep things public while giving more exposure to the newer members on the team. One thing I like to do is ensure a contributor has a Mozillians profile as well as links to other discoverable things (bugzilla id, irc nick, github id, twitter, etc.) and some information about why they are participating. In addition to this, we also highlighted achievements in the fortnightly Engineering Productivity meeting and any other newsgroup postings we were doing.

Lastly I would like to point out a dedicated mentor was successful. As a contributor it is not always comfortable to ask questions, or deal with reviews from a lot of new people. Having someone to chat with every day you are hacking on the project is nice. Being a mentor doesn’t mean reviewing every line of code, but it does mean checking in on contributors regularly, ensuring bugs are not stuck waiting for needinfo/reviews, and helping set expectations of how work is to be done. In an ideal world after working on a project like this a contributor would continue on and try to work with a new mentor to grow their skills in working with others as well as different code bases.

What we can do differently next time?

A few small things are worth improving on for our next cycle, here is a few things we will plan on doing differently:

Advertising 4-5 weeks prior and having a defined start/end date (e.g. November 20th – January 15th)
Really limiting this to a specific number of contributors, ideally 2-3 per mentor.
Setting acceptance criteria up front. This could be solving 2 easy bugs prior to the start date.
Posting an announcement welcoming the new team members, posting another announcement at the halfway mark, and posting a completion announcement highlighting the great work.
Setting up a weekly meeting schedule that includes status per person, great achievements, problems, and some kind of learning (guest speaker, Q&A, etc.). This meeting should be unique per project.
Have a simple process for helping folks transition out of they have less time than they thought- this will happen, we need to account for it so the remaining contributors get the most out of the program.

In summary we found this to be a great experience and are looking to do another program in the near future. We named this Summer of Contribution for our first time around, but that is limiting to when it can take place and doesn’t respect the fact that the southern hemisphere is experiencing Winter during that time. With that :maja_zf suggested calling it Quarter of Contribution which we plan to announce our next iteration in the coming weeks!