Hello WebKittens,
At the WebKit contributors meeting, we held a session to brainstorm ways to
increase the size of the WebKit community.
(You can see our notes on the wiki:
http://trac.webkit.org/wiki/November%202015%20Meeting
<http://trac.webkit.org/wiki/November%202015%20Meeting>)
One thing that we really liked about some other projects, particularly Mozilla
projects such as Servo, Rust, and Firefox,
is that there are bugs explicitly marked as being “Easy” or a “Good First Bug”
in Bugzilla. I think we should try this.
Here are some reasons why this works well (and what we should try to emulate):
- Bugs are flagged by experienced contributors who are familiar with the
feature or component in question. Identifying
a good place to start is a big deal: in practice, most Bugzilla instances are
chockfull of stale, misleading, or outright wrong
bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if
components and bugs were always current, there
are simply thousands of real, actionable tasks which are hard for new
contributors to judge without domain expertise.
In WebKit’s Bugzilla instance, we are going to use the GoodFirstBug and EasyFix
keywords to track such bugs.
Once some mentored bugs exist, we may want to think about setting up a gateway
like Bugs Ahoy! to make searching easier.
- Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor” who
can help a new contributor get up to speed.
There is a lot of process to be learned to fix even a trivial bug: getting the
code, building, making changes, writing tests,
creating and uploading a patch, going through review, and getting changes in
the tree. In my experience, new folks are happy
to read and write code, but are easily discouraged from finishing a patch
because of these barriers. A mentor helps coach
and encourage a new contributor through these parts of the process. Some
Bugzilla instances have a field for this; for
now, just ensure a mentor (you or someone else) is CC’d and responsive to
questions from the contributor on Bugzilla.
- A potential fix for a good first bug should be straightforward, described in
Bugzilla, and be covered by new or existing tests.
This allows a new contributor to achieve a development feedback loop as to
whether their changes have correct behavior without
requiring extra effort on the part of mentors. It also educates and instills
good habits, like writing tests alongside (or even before!) making changes.
- Patches from new contributors are reviewed quickly and regularly. Getting
quick feedback is essential to retaining interest
and momentum, especially for contributors without an economic motivation (i.e,
a job) or long-term history with the project.
Feedback should be actionable and constructive. It’s much better to mark a
patch as review- unless it’s ready to land, than to
let a patch linger with open questions and the review? flag set. This
discourages new contributors since the next step is unclear.
Remember, good first bugs serve primarily as an introduction to the process of
contributing code changes, so they may not
be particularly interesting to an experienced contributor. Ramping up new
contributors takes time and effort, but it’s worth it.
Have any questions? Feel free to respond, find us on #webkit IRC, or contact
myself or Jon Davis.
-Brian
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
