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

[Alex Bradbury via llvm-dev]

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

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

# 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