6 ms·

Contributors do not save time

50 points by pferde 10y ago

Sir_Cmpwn 10y ago
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.
- cm3 10y ago
  I do the same, but I wish more contributors who just want to dump a patch would say so from the get go. Otherwise, you start debating why a certain change needs to be made, and only after a couple days they say "please, take it or leave it". It's not wrong to just dump a patch, but include it in the description, and if the change is useful, I will rework the patch to fit. Thankfully, such contributors have been rare in the projects I'm involved in.
- scribu 10y ago
  My hunch is that there are several factors that make outside contributions easier to leverage or less so. One of course is the maintainer's ability to mentor new contributors into becoming co-maintainers - writing guides etc. Another would be a project's scope. If it's really small, then people will step on each other's toes. Yet another would be "fun-ness" - how intrinsically rewarding it is to work on the project. It would be alot harder to get people to stick around if they find the work tedious.
- nickpsecurity 10y ago
  You reference those here and there. Curious what projects you work on, esp OS-related?
  - Sir_Cmpwn 10y ago
    Check out my Github: https://github.com/SirCmpwn https://github.com/SirCmpwn The pinned projects there are groomed.
    - nickpsecurity 10y ago
      "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 10y ago
        Of course, feel free. I enjoy reinventing the wheel :)
eyelidlessness 10y ago
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 10y ago
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.
- eyelidlessness 10y ago
  I'd suggest adopting a model that works for your workflow and your project goals, and asking contributors to adopt it as well. Github can also help accommodate this if you want. Example: - Your project has two mainline branches, one against which development is done and the other from which releases are cut. - The development mainline is the default branch - this is the first thing contributors see, and the first branch PRs target - You "adopt" PRs into the development branch, and when you feel the work is suitable, release it to the release mainline branch
  - timthelion 10y ago
    Well, the method still isn't perfect, due to the lack of easy, well formated, ability to communicate to the contributor why the PR's commits were changed. The current UI creates a default culture of really tense back and forth nitpicking comments.
    - logingone 10y ago
      Depending on the size of the nits you might be able to merge as is, then open a new issue to address the nits.
      - 10y ago
allengeorge 10y ago
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.
Manishearth 10y ago
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-open-source-project-newcomer-friendly/ http://manishearth.github.io/blog/2016/01/03/making-your-ope.... 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.
grhmc 10y ago
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-considered-harmful/ https://blog.spreedly.com/2014/06/24/merge-pull-request-cons...
mizzao 10y ago
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.

50 points by pferde 10y ago

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.

cm3 10y ago
I do the same, but I wish more contributors who just want to dump a patch would say so from the get go. Otherwise, you start debating why a certain change needs to be made, and only after a couple days they say "please, take it or leave it". It's not wrong to just dump a patch, but include it in the description, and if the change is useful, I will rework the patch to fit. Thankfully, such contributors have been rare in the projects I'm involved in.
scribu 10y ago
My hunch is that there are several factors that make outside contributions easier to leverage or less so. One of course is the maintainer's ability to mentor new contributors into becoming co-maintainers - writing guides etc. Another would be a project's scope. If it's really small, then people will step on each other's toes. Yet another would be "fun-ness" - how intrinsically rewarding it is to work on the project. It would be alot harder to get people to stick around if they find the work tedious.
nickpsecurity 10y ago
You reference those here and there. Curious what projects you work on, esp OS-related?
- Sir_Cmpwn 10y ago
  Check out my Github: https://github.com/SirCmpwn https://github.com/SirCmpwn The pinned projects there are groomed.
  - nickpsecurity 10y ago
    "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 10y ago
      Of course, feel free. I enjoy reinventing the wheel :)

eyelidlessness 10y ago

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 10y ago

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.

eyelidlessness 10y ago
I'd suggest adopting a model that works for your workflow and your project goals, and asking contributors to adopt it as well. Github can also help accommodate this if you want. Example: - Your project has two mainline branches, one against which development is done and the other from which releases are cut. - The development mainline is the default branch - this is the first thing contributors see, and the first branch PRs target - You "adopt" PRs into the development branch, and when you feel the work is suitable, release it to the release mainline branch
- timthelion 10y ago
  Well, the method still isn't perfect, due to the lack of easy, well formated, ability to communicate to the contributor why the PR's commits were changed. The current UI creates a default culture of really tense back and forth nitpicking comments.
  - logingone 10y ago
    Depending on the size of the nits you might be able to merge as is, then open a new issue to address the nits.
    - 10y ago

allengeorge 10y ago

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.

Manishearth 10y ago

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-open-source-project-newcomer-friendly/ http://manishearth.github.io/blog/2016/01/03/making-your-ope.... 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.

grhmc 10y ago

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-considered-harmful/ https://blog.spreedly.com/2014/06/24/merge-pull-request-cons...

mizzao 10y ago

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.