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