[llvm-dev] RFC: Improving the experience of first-time contributors
Robinson, Paul via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 1 07:59:43 PDT 2016
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Alex
> Bradbury via llvm-dev
> Sent: Tuesday, November 01, 2016 6:17 AM
> To: llvm-dev
> Subject: [llvm-dev] RFC: Improving the experience of first-time
> 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-
> Video: https://www.youtube.com/watch?v=32fmbEI9WrM
> # 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.
It's not just first-time contributors who can have this problem...
...but it can be especially off-putting to first-timers.
> # 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.
That's an awesome idea for people who do actually post a patch to
phabricator. I'll just point out that phabricator isn't officially
required, and is in fact an extra barrier to entry, so we should
have some tactic for handling emailed patches if we can manage it.
I know people will react with "what barrier?" but it's YADA
(Yet Another Damn Account) and I know *I* hate doing that for
something I view as a one-off.
> One potential pitfall I'd like to highlight is that many patches
> really require the sign-off of the code owner. 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.
People who sign up to be first-responders :-) should probably have
some sense of when patches are of that nature, and say so in their
initial response. If nothing else, cosmetic feedback will get new
contributors in tune with our style guide and make subsequent rounds
feel more substantive/less picky.
> # 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.
Agreed. Partly it's the raw size of the project; when I was on a
two-person team it was never a problem to get reviews done, but
with a dozen or more and looking for someone to volunteer, there's
a significant "somebody else will get to it" factor. And then nobody
does. With volunteer first-responders it's something they've signed
up to do, however, and that makes a big difference.
> 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?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev