[llvm-dev] RFC: Improving the experience of first-time contributors

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 1 09:42:17 PDT 2016


> On Nov 1, 2016, at 6:17 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi all,
> 
> Some discussions the night before prompted me to do a short lightning
> talk on 'improving the experience of first-time contributors' at the
> LLVM Cauldron back in September. I intended to write it up as an RFC,
> but have only just got round to doing so. I've tried to make this
> email self-contained, but you may still want to look at the slides or
> recording of the lightning talk.
> 
> Slides: https://speakerdeck.com/asb/can-we-improve-the-experience-of-first-time-llvm-contributors
> Video: https://www.youtube.com/watch?v=32fmbEI9WrM <https://www.youtube.com/watch?v=32fmbEI9WrM>

Great initiative! Thanks.

Have you seen this past discussion: http://lists.llvm.org/pipermail/llvm-dev/2016-March/097027.html
I think the main idea has been to set-up a regular IRC session dedicated to “new contributors”.

> 
> # The problem
> As a first-time contributor, it's easy to be put off during the patch
> submission process. e.g. the patch may sit unreviewed for weeks.
> Typically people new to the project haven't yet reviewed 'review
> currency', and so their patches are less likely to be picked out by
> others scanning through llvm-commits. Obviously nobody is doing
> anything wrong here, it's just likely to be off-putting to newcomers.
> Even if feedback is negative, it's valuable to know someone has at
> least looked at your code.
> 
> # How do other projects solve this?
> I've always been impressed at how Rust has been able to attract a
> steady stream of new contributors. They have a simple but seemingly
> effective tool for helping people land their first patch: the highfive
> bot. Upon a user making their first pull request, it posts a welcome
> message and assigns someone to review it.
> 
> # A proposal
> I propose that we form a group of people who specifically volunteer to
> help review first-time patches. A simple phabricator bot could assign
> someone randomly much like Rust's highfive.
> 
> One potential pitfall I'd like to highlight is that many patches
> really require the sign-off of the code owner.

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: http://llvm.org/docs/DeveloperPolicy.html#code-owners "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."
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.


> It could be equally
> frustrating for newcomers if people helpfully tell them to tweak their
> variable names, fix their formatting, and make other cosmetic changes
> only to find that time was wasted when the code owner step in a week
> or two later to say a completely different approach needs to be used.

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).

Best,

— 
Mehdi



> 
> # Next steps
> 
> Does anybody have any views here? My 'raise your hand' poll at the
> LLVM Cauldron did seem to think many felt things could be improved.
> I'll be at the LLVM Dev Meeting this week and would love to discuss
> further. Perhaps the BoF on raising the next generation of LLVM
> developers would be an appropriate venue?
> http://lists.llvm.org/pipermail/llvm-dev/2016-October/106658.html
> 
> Best,
> 
> Alex
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161101/62717283/attachment.html>


More information about the llvm-dev mailing list