<div dir="ltr"><div><div><div><div><div><div>That sounds like a really cool idea, I just filed one such bug :)<br><br></div></div>So, what is the difference between EasyFix and GoodFirstBug?<br></div>Should we use both?<br><br></div><div>Below some additional points.<br></div><div>Thanks,<br></div><div> y<br><br></div><div>The initial entry point for some people is WebKit github mirror.<br></div>Would it make sense to express a few contribution information there? Something like:<br></div>- Contributors are most welcome :) List of good first bugs can be found at XXX. Expected review time for those bugs should be fairly quick (1 or 2 days?) <br></div>- Contribution system is bugzilla, pull requests not accepted through github<br><div><div><div><div><div><div><div><div>- Build instructions can be found at XXX for Mac, YYY for Linux and ZZZ for Windows<br></div><div><div><div><br></div>As a newcomer, it is difficult to know whether a patch review should be expected by the day, the week or the month. Knowing that is useful to react properly.<br><div><br><div>In my experience, it is also not only about quickly reviewing newcomers patches but also about the harder task of being responsive to initial comments they may make on new/existing bugs.Having such responses may convince them to actually write their first patches.<br><br></div>The tools used to prepare patches are handy but still require some practice and may be frustrating, like ChangeLog generation for instance.<br>I wonder whether it is worth/difficult to translate a github pull request/github issue as a new bugzilla entry w/o patch. That may be handy for newcomers as well.<br></div><br></div></div></div></div></div></div></div></div></div><div class="gmail_quote"><div dir="ltr">Le lun. 14 déc. 2015 à 18:53, Brian Burg <<a href="mailto:bburg@apple.com" target="_blank">bburg@apple.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello WebKittens,<br><div><font color="#5856d6"><br></font>At the WebKit contributors meeting, we held a session to brainstorm ways to increase the size of the WebKit community.<br>(You can see our notes on the wiki: <a href="http://trac.webkit.org/wiki/November%202015%20Meeting" target="_blank">http://trac.webkit.org/wiki/November%202015%20Meeting</a>)<br><font color="#5856d6"><br></font>One thing that we really liked about some other projects, particularly Mozilla projects such as Servo, Rust, and Firefox,<br>is that there are bugs explicitly marked as being “Easy” or a “Good First Bug” in Bugzilla. I think we should try this.<br><font color="#5856d6"><br></font>Here are some reasons why this works well (and what we should try to emulate):<br><font color="#5856d6"><br></font>- <b>Bugs are flagged by experienced contributors who are familiar with the feature or component in question</b>. Identifying<br>a good place to start is a big deal: in practice, most Bugzilla instances are chockfull of stale, misleading, or outright wrong<br>bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if components and bugs were always current, there<br>are simply thousands of real, actionable tasks which are hard for new contributors to judge without domain expertise.<br>In WebKit’s Bugzilla instance, we are going to use the <b>GoodFirstBug and EasyFix keywords</b> to track such bugs.<br><font color="#5856d6"><br></font>Once some mentored bugs exist, we may want to think about setting up a gateway like Bugs Ahoy! to make searching easier.<br><font color="#5856d6"><br></font>- <b>Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor”</b> who can help a new contributor get up to speed.<br>There is a lot of process to be learned to fix even a trivial bug: getting the code, building, making changes, writing tests,<br>creating and uploading a patch, going through review, and getting changes in the tree. In my experience, new folks are happy<br>to read and write code, but are easily discouraged from finishing a patch because of these barriers. A mentor helps coach<br>and encourage a new contributor through these parts of the process.<b> </b>Some Bugzilla instances have a field for this; for<br>now<b>, </b>just<b> ensure a mentor (you or someone else) is CC’d and responsive to questions from the contributor on Bugzilla.</b><br><font color="#5856d6"><br></font>- <b>A potential fix for a good first bug should be straightforward, described in Bugzilla, and be covered by new or existing tests.</b><br>This allows a new contributor to achieve a development feedback loop as to whether their changes have correct behavior without<br>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><font color="#5856d6"><br></font>- <b>Patches from new contributors are reviewed quickly and regularly.</b> Getting quick feedback is essential to retaining interest<br>and momentum, especially for contributors without an economic motivation (i.e, a job) or long-term history with the project.<br>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>let a patch linger with open questions and the review? flag set. This discourages new contributors since the next step is unclear.<br><font color="#5856d6"><br></font>Remember, good first bugs serve primarily as an introduction to the process of contributing code changes, so they may not<br>be particularly interesting to an experienced contributor. Ramping up new contributors takes time and effort, but it’s worth it.<br><font color="#5856d6"><br><br></font>Have any questions? Feel free to respond, find us on #webkit IRC, or contact myself or Jon Davis.<br><font color="#5856d6"><br></font><div style="word-wrap:break-word"><div><span style="white-space:pre-wrap"> </span>-Brian</div>
</div></div><br></div>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</blockquote></div></div>