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

Reply via email to