Attracting and retaining new contributors

Mozillians
#1

This is a continuation of the discussion held at Mozlando about how to lay a path for new contributors to Mozilla codebases.

Copying over Joel’s summary of the topics discussed:

  • difficulty of creating good “good first bugs”
  • what to do after a few easier bugs
  • critical path vs usefulness for the type of bugs to mentor
  • mentoring vs handholding
  • expectations of contributors
  • :jaws point of view on his 5 contributors for a quarter
  • should we be teaching coding (like capture the flag) via gamification or pre-canned projects?
  • probably a few other things I am not remembering right now!

Feel free to post more ideas or thoughts here!

2 Likes
#2

To get this started, some things which we have tried at Servo

  • Consciously trying to create easy bugs when working on things: If there are noncritical portions of a feature you are working on (e.g. polish, or a small subfeature that can be logically separated out), see if it can be made into an easy bug.
  • Changing process for new contributors: We love our tools and process, but many of them aren’t necessary for small PRs from people new to the process. See if an alternate process can be created that is much simpler, and over the next few contributions usher the contributor over to the regular process.

Right now for Rust I’m slowly curating the easy bugs and creating more by identifying types of bugs which are often easy (e.g. for Rust this is diagnostics). I also try to ensure that easy bugs have enough tips on them for someone to get started without help (since avoid asynchronous communication is slow).

Rust, being a compiler, is somewhat intimidating, so I sometimes send new contributors to other Rust projects which deal with compilery things (like rustfmt and rust-clippy, both of which have tons of easy bugs), after which they are much more confident.

2 Likes
#3

A way that I suggest (many times) is to work on already fixed bug.
In this way we can choose the best bug for help people how to learn and they have the correct code in case of problem also for studying.
The problem of that solution is pick an old version of the software but this is a little problem because in that way the contributor can be followed in the various step.

#4

Even though I can see how having a well laid path forward (e.g. already fixed bugs) less frustrating, I think that would undermine the motivation in the long run. Also, this would probably make contributors feel like having less to no impact at all on the project, as the changes already landed.

With Telemetry (Firefox Desktop), similarly to Servo, we try to create easy, well scoped bugs to guide new contributors to know the tools we use and our process. Then, we try to retain contributors by suggesting increasingly challenging bugs (within Telemetry, unless we run out of them :-/ ).

Our lunch meeting got me thinking about how “easy” are our “easy” bugs. As of now, we guide the contributor, step by step, to each line she/he needs to change. Maybe that’s a bit too much, and could make a landed patch not feel like an accomplishment at all.

That said, +1 to having less process burden for new contributors, but I think that picking up the skills & tools (even if a small set) they would use with future contributions is helpful.

1 Like
#5

Great thread, some questions I have!

  1. Can good first bugs also represent the onboarding to a project? For example ‘setup environment’, ‘read about our development and release cycle , and answer these self assesment questions’, 'read through the description of our technology stack and answer these 3 self-assessment about ‘how you can help’.

A lot of these happen informally when taking a bug, but I think being more deliberate about mliestones in success outside of just the bug itself, can help people feel successful sooner. It can also help limit questions, and establish a community goal to help each other through those first bugs.

  1. What assumptions are we making about onboarding contributors to be the same as teaching new coders? In some cases we have people with advanced backgrounds in software engineering turning out, but it’s our processes, lingo that deflects their participation. How can we create ‘good first bugs’ for advanced coders, as well as newbies - meaning we don’t waste their time with irrelevant, or non-critical tasks once they are onboarded.

  2. How do we allow people to introduce ways they know they can help, vrs the ways we think they can. That might be that a technical writer turns up, how do they get involved ?

  3. How do you prepare mentors, because yes people have different ideas about what means. How long is the relationship, how do you protect the time of a mentor generally? What processes and tools can make it easier. How do you design this with diversity in mind?

  4. +1 on the comment that contributors want to have impact. How can we reflect impact of contributions.

3 Likes
#6

I would like to outline a few things we have done on the A*Team over the last 2 years.

Good First Bugs:
In the past we have done pushes to create good first bugs, this is a rewarding process and it seems as soon as you create bugs, they get picked up. Problems we have had here fall into “what else can I do” and “lack of people exciting about mentoring”.

Good Next Bugs and Projects:
Iterating on Good First Bugs, we found that after setting up to work on a project, it would be nice to keep working on the same project, module, feature, file. This meant that we pushed hard on specific projects and mentors to create a set of bugs (a few Good First Bugs, then many Good Next Bugs). This approach had success and solved the “what else can be done” problem from above. In fact we still use this approach somewhat. The main problems we had here were “lack of people exciting about mentoring” and “how to keep up to date”

Quarter of Contribution:
The latest version of our hacking was after brainstorming what brought the most value out of the mentor/contributor equation. The big problem of “lack of people exciting about mentoring” has to do with mentors having the perception that mentoring is not a productive use of their time and that people will come, not finish a bug, and then disappear. Yes, this is true, it happens all the time. The QoC is designed to allow for a mentor/contributor relationship to build up and for something more substantial to be built. This is not a program for everyone, but this does address many of the concerns about mentoring. While logistics are getting easier with each iteration (we are on the 2nd instance of this), the process of selecting a project or a larger set of bugs remains doable in a day or two of work. We find that contributors can get a lot more done that we imagine. After completing the original work, they bring great ideas to the table and we can let it grow naturally.

Other things to consider:

  • Mentoring is not for everyone, lets not force people, rather lead by example
  • We should nudge, but not help too much- people want to learn
  • There is a need for mentor training- I would like to see that in 2016.
  • Every team has a dynamic that works differently- what we have done is working for us, the more we share the more we can try
  • We are looking to only do 2 QoC/year on the A*Team, the other quarters will be focused on good first bug pushes and making our projects more accessible.
  • Setting quarterly goals or deliverables around community will ensure it gets done and that others understand your priorities (and can help!)
4 Likes
#7

Very important.

and this !

1 Like
#8

I would find that useful as well!

2 Likes
#9

Although created for Rep Mentors, I think there are some bits to steal for other mentorship training here:

http://education.mozilla-community.org/modules/reps_mentor_training/introduction/

#10

Sometimes what I like to do is give someone (especially less experienced folks) dead simple bugs like “replace this string” or other one-line changes. This lets them familiarize themselves with the process whilst not having to bother with the code too much.

We usually have a range of difficulties in the easy bug bracket. For folks which are more experienced than this range, we also have “less easy” and “hard” bugs (still earmarked for new contributors and mentorship, but not easy anymore). These usually get taken by existing contributors who want to work on harder stuff, but sometimes new contributors take them.

With Rust there’s a lot of writing that can be done in documentation and diagnostics, and we encourage people to work on this stuff.

I don’t have an answer for this (I do nudge people into mentoring, but I don’t “mentor the mentors” much aside from small tips here and there and some supervision).

However, I do feel that this is a super important thing which we should figure out, however, and would love to see everyone’s ideas and thoughts on how to correctly mentor. (My own thoughts on this will be in a blog post coming soon which I’m halfway finished writing)

1 Like
#11

Wrote up some stuff on this topic: http://manishearth.github.io/blog/2016/01/03/making-your-open-source-project-newcomer-friendly/

1 Like
#12

Great post!