<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 1, 2016, at 6:17 AM, Alex Bradbury via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">Some discussions the night before prompted me to do a short lightning<br class="">talk on 'improving the experience of first-time contributors' at the<br class="">LLVM Cauldron back in September. I intended to write it up as an RFC,<br class="">but have only just got round to doing so. I've tried to make this<br class="">email self-contained, but you may still want to look at the slides or<br class="">recording of the lightning talk.<br class=""><br class="">Slides: <a href="https://speakerdeck.com/asb/can-we-improve-the-experience-of-first-time-llvm-contributors" class="">https://speakerdeck.com/asb/can-we-improve-the-experience-of-first-time-llvm-contributors</a><br class="">Video: <a href="https://www.youtube.com/watch?v=32fmbEI9WrM" class="">https://www.youtube.com/watch?v=32fmbEI9WrM</a><br class=""></div></div></blockquote><div><br class=""></div><div>Great initiative! Thanks.</div><div><br class=""></div><div>Have you seen this past discussion: <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-March/097027.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-March/097027.html</a></div><div>I think the main idea has been to set-up a regular IRC session dedicated to “new contributors”.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""># The problem<br class="">As a first-time contributor, it's easy to be put off during the patch<br class="">submission process. e.g. the patch may sit unreviewed for weeks.<br class="">Typically people new to the project haven't yet reviewed 'review<br class="">currency', and so their patches are less likely to be picked out by<br class="">others scanning through llvm-commits. Obviously nobody is doing<br class="">anything wrong here, it's just likely to be off-putting to newcomers.<br class="">Even if feedback is negative, it's valuable to know someone has at<br class="">least looked at your code.<br class=""><br class=""># How do other projects solve this?<br class="">I've always been impressed at how Rust has been able to attract a<br class="">steady stream of new contributors. They have a simple but seemingly<br class="">effective tool for helping people land their first patch: the highfive<br class="">bot. Upon a user making their first pull request, it posts a welcome<br class="">message and assigns someone to review it.<br class=""><br class=""># A proposal<br class="">I propose that we form a group of people who specifically volunteer to<br class="">help review first-time patches. A simple phabricator bot could assign<br class="">someone randomly much like Rust's highfive.<br class=""><br class="">One potential pitfall I'd like to highlight is that many patches<br class="">really require the sign-off of the code owner. </div></div></blockquote><div><br class=""></div><div>I don’t believe it is exact, unless you used “code owner” in a broader sense that what we mean usually with CODE_OWNERS.txt ; as you can see here: <a href="http://llvm.org/docs/DeveloperPolicy.html#code-owners" class="">http://llvm.org/docs/DeveloperPolicy.html#code-owners</a> "The sole responsibility of a code owner is to ensure that a commit to their area of the code is appropriately reviewed, either by themself or by someone else."</div><div>You may need a sign-off from a “core contributor” well aware of the particular area you’re touching. And even that depends on the level of the changes: a small bug fix is less involved than something that requires large change or involves some design.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">It could be equally<br class="">frustrating for newcomers if people helpfully tell them to tweak their<br class="">variable names, fix their formatting, and make other cosmetic changes<br class="">only to find that time was wasted when the code owner step in a week<br class="">or two later to say a completely different approach needs to be used.<br class=""></div></div></blockquote><div><br class=""></div><div>I hope the “group of volunteers” will be well aware of LLVM and be able to spot when they need to pull-in someone else for a particular review (e.g. an important change in the new pass manager is likely to require Chandler to sign-off).</div><div><br class=""></div><div>Best,</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""># Next steps<br class=""><br class="">Does anybody have any views here? My 'raise your hand' poll at the<br class="">LLVM Cauldron did seem to think many felt things could be improved.<br class="">I'll be at the LLVM Dev Meeting this week and would love to discuss<br class="">further. Perhaps the BoF on raising the next generation of LLVM<br class="">developers would be an appropriate venue?<br class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2016-October/106658.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-October/106658.html</a><br class=""><br class="">Best,<br class=""><br class="">Alex<br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class="">llvm-dev@lists.llvm.org<br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></div></blockquote></div><br class=""></body></html>