[webkit-dev] Use the 'EasyFix' and 'GoodFirstBug' Bugzilla keywords to mentor WebKit newcomers!

[Brian Burg]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151214/bda6be65/attachment.html>