
Contributors do not save time - pferde
http://www.drmaciver.com/2016/07/contributors-do-not-save-time/
======
Sir_Cmpwn
This is very much untrue. I manage several open source projects and
contributors save me _tons_ of time. You have to mold contributors into the
productive team members you need them to be to save you time. I often receive
pull requests from first time contributors that are not immediately mergable.
I don't take the approach of just merging it and fixing it myself - I do
invest the time in coaching the contributor into making their pull request a
strong candidate for merge on their own. This often produces returning
contributors who get it right more and more often on the first try and can be
trusted to write larger and more important swaths of the code. Bonus - these
contributors you've worked with will often start to get in and help review
entry-level pull requests, too, which reduces your workload even more for
onboarding new contributors.

Contributors rock! More of them would help me get my projects done _so much_
faster.

~~~
nickpsecurity
You reference those here and there. Curious what projects you work on, esp OS-
related?

~~~
Sir_Cmpwn
Check out my Github:
[https://github.com/SirCmpwn](https://github.com/SirCmpwn)

The pinned projects there are groomed.

~~~
nickpsecurity
"I make unoriginal projects with better code than the thing they rip off."

Love that line. That's what we high-assurance people keep telling developers
to do to all the established stuff. You said it better, though. Might remix
that in some way with your permission. :)

~~~
Sir_Cmpwn
Of course, feel free. I enjoy reinventing the wheel :)

------
eyelidlessness
I think the author misses a key point.

The article begins by laying out a premise that not all work is equal, in the
sense that contributors will contribute work that maintainers aren't wont to
do for one reason or another.

But what follows is the claim that this creates an additional work burden for
maintainers, in terms of review. But what is each contribution, and how does
it contribute to future work by maintainers and contributors alike?

Projects with a lot of attention benefit not just from "work" but from
advancing design and efficiency where, as the author says, "each contributor
brings fresh eyes and experience to the project". Simply counting hours worked
doesn't account for this, because a tremendous amount of work may simply be
avoided by this kind of contribution.

------
timthelion
My feeling is that this is actually a problem with github and the "pull
request" method specifically. All of the back and forth, waiting for the
contributor to update commits is a huge time sink for me. It takes 10x as much
effort to merge a small pull request than to actually write the code myself.

The solution I see, is to make it so that rather than commenting on pull
requests, I "adopt" the pull requests. I merge them into a private branch, fix
the spelling errors and the "bad" variable names, and then I push the bundle.
For some reason, most contributors want to have a clean commit history and
don't like this method. I agree that it is messy. I think that my "solution"
points to the need for a better solution. Either one implemented by github or
one implemented by a competitor which destroys github.

~~~
Manishearth
I often do this. I will merge the PR with my fixes, and leave a comment for
the new contributor letting them know the fixes I made (so they can do it
themselves next time before making the PR).

~~~
timthelion
I do this too. But it just doesn't feel natural on github. I feel like I'm
doing something that is "unusual".

------
allengeorge
Well, the writer is correct: dealing with a contributor increases your own
workload. But...maybe we could use the interaction to turn an occasional
contributor into a maintainer? Although that's tough, hopefully the
contributor grows into that role and, over time, reduces your own workload as
well.

------
grhmc
For fixing simple stylistic / spelling problems, I really like the take taken
with `git am`: [https://blog.spreedly.com/2014/06/24/merge-pull-request-
cons...](https://blog.spreedly.com/2014/06/24/merge-pull-request-considered-
harmful/)

------
mizzao
I think what the author writes is true if you want to maintain absolute
control over the project.

However, in this post ([http://felixge.de/2013/03/11/the-pull-request-
hack.html](http://felixge.de/2013/03/11/the-pull-request-hack.html)) and the
related HN discussion
([https://news.ycombinator.com/item?id=5357417](https://news.ycombinator.com/item?id=5357417)),
we see that by empowering and trusting contributors we can often get
surprising and unintuitive results. I've tentatively tried this and been
pleasantly surprised in my own projects.

------
Manishearth
I disagree. I recognize that the author is writing based on their experiences,
but that should not paint all contributors that way.

I'm involved in two projects (Rust, Servo) which have _immense_ numbers of
contributions from volunteers. Both have mentorship programs (Servo's is more
evolved, Rust's is getting on its feet). In Servo we spend a lot of time
mentoring people. In return, once every few new contributors we get someone
who sticks around, and perhaps even works on major things. This saves ton of
time. I haven't ever measured this formally, but by eyeballing it I'd say
contributors save more time than the review process and mentorship take.

I also have a personal project, rust-clippy
([http://github.com/manishearth/rust-
clippy/](http://github.com/manishearth/rust-clippy/)). It started out as my
own thing, and I merged with another similar project and got a co-maintainer.
It was mostly the two of us working on it. We could have gotten it to the
stage which it is at now, but it would have taken forever. At one point I
started tagging issues as easy/medium/hard, and wrote some documentation for
newbies wanting to contribute. I advertised this a bit in the appropriate
forums, and now I have tons of contributors; three of which have become
maintainers (they still contribute a lot), and a couple others who frequently
contribute. I don't have much time to work on this project these days, but it
has grown _so much_ without me needing to put much time in it at all. These
days I mostly review PRs and take part in discussions, but rarely write code
for it. The project is now a tool with more than 150 lints which most of the
Rust community uses and loves. It would not have gotten there without the
contributors.

If you'd like your project to be mroe receptive to new contributors, I have a
blog post I once wrote for this:
[http://manishearth.github.io/blog/2016/01/03/making-your-
ope...](http://manishearth.github.io/blog/2016/01/03/making-your-open-source-
project-newcomer-friendly/). Many of the tips there don't require much effort
-- it's either a one-time thing you have to do, or a change in process that
doesn't make the process longer.

Aside: Often a distinction between "contributor" and "maintainer" is made, and
this is cropping up in this thread too. In clippy this has never really been a
thing. We have maintainers, but when someone becomes a maintainer they don't
really do anything different -- they don't take on more responsibilities.
Rather, most of the contributors I have ramp up from working on individual
issues to reviewing and doing maintainer-y things, and once we think they've
got the gist of it we give them merge powers. In Servo/Rust we also have a
similar continuum -- we have folks who take part in review without having
review access ("review access" is the ability to tell our autoland bot that
something is reviewed and ready to test/merge), and at some point they are
given reviewer permissions. So there is of course a difference in the powers
available to contributors and maintainers, but in the projects I work on the
most there's not much of a difference in what they _do_ ; maintainers don't
have additional responsibilities, they just have powers which help they carry
out what they were doing as a contributor anyway.

~~~
dpc_pw
Rust is particularly good at it. It makes bugs finding easier as language
forces good habits and eliminates whole classes of bugs, tests are easy to add
and check, ecosystem has established ways of dealing with CIs, reviews, good
autoformatting tools, there's `clippy` for good style, etc.

