5 ms·

Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay. The real secret to not burning out is to scal

by ef4 9y ago

Color me deeply skeptical of the suggestion to try to lock people out of community participation unless they pay. The real secret to not burning out is to scale up the set of maintainers in proportion to the users. You do that by lowering the barriers to involvement, not raising them. Most maintainers err on the side of controlling too much. Which makes them into bottlenecks. One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers. Bad commits can be easily reverted. Whereas giving people a bit of trust often inspires them to help more.

asdfasdfasd333 9y ago
Absolutely this. This applies to engineering at software companies as well.
Klathmon 9y ago
I completely agree, the only thing I still like to keep to myself (or to a very select group) is the ability to cut a release. If you want commit access, just ask. But I still want to validate releases that get pushed out to a bunch of people.
- mjevans 9y ago
  My policy is to never ask, and to only accept if I think I can be worthy of the work at the time (so I might accept at a later date if I feel I don't have the bandwidth today).
  - Klathmon 9y ago
    And I tend to try and offer if i start to notice the name in a few issues or PRs.
zzzeek 9y ago
Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.
- bartread 9y ago
  Superficially, that sounds more like a release process issue than a bad commit issue.
- nextlevelwizard 9y ago
  How often is commit bad enough to require revert, yet made it through testing and got released?
  - btown 9y ago
    Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.
    - diggan 9y ago
      All those things should and hopefully would have been caught when the PR was made, not after the commits made it into master.
      - btown 9y ago
        The entire context of this thread is that adding committers can introduce risk in the quality of accepted contributions. Building a trusted network of gatekeepers is hard.
        nextlevelwizard 9y ago
        Just because stuff gets to master doesn't mean they get to the release.
    - snakeanus 9y ago
      > Code style How is that an issue in this day and age? Just run astyle or indent.
hacking_again 9y ago
> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers. In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.
imhoguy 9y ago
"a bit of trust" this! Most often maintainers ego is the issue and too much control over ones baby project is the road to frustration and burnout. The way the power is shared and the shape of community structure is huge factor often neglected by tech-only focused maintainers/owners. There is a good piece of wisdom on social aspect of open-source in Social Architecture by Pieter Hintjens[0]. I recommend learning about his pov to anyone interested in open-source open-projects. [0] https://www.gitbook.com/book/hintjens/social-architecture/details https://www.gitbook.com/book/hintjens/social-architecture/de...
- ngrilly 9y ago
  Excellent read! Thanks!
ATsch 9y ago
A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master
- lamby 9y ago
  You can do this on Github with custom hooks etc. But yes.
  - hnlmorg 9y ago
    That's potentially one way of doing it but Github does also have a specific feature for doing this literally called "Protected branches": https://github.com/blog/2051-protected-branches-and-required-status-checks https://github.com/blog/2051-protected-branches-and-required...
- eb3c90 9y ago
  You can do this now. $work uses github and has it so that a bit of code has to have be reviewed before it can be merged to master.
- hnlmorg 9y ago
  You can do this on Github. It's even called the same. Go to your repo -> settings -> branches and it's the 2nd item (Protected branched). I use this feature at work so I can confirm it behaves as expected.
  - ATsch 9y ago
    Oh, great! I tried it a while ago and the setting was nowhere to be found!
j_s 9y ago
The Pull Request Hack | https://news.ycombinator.com/item?id=5357417 https://news.ycombinator.com/item?id=5357417 (March 2013) http://felixge.de/2013/03/11/the-pull-request-hack.html http://felixge.de/2013/03/11/the-pull-request-hack.html > Whenever somebody sends you a pull request, give them commit access to your project. I agree with requiring more accountability before granting the ability to create official releases.
ngo123 9y ago
> Most maintainers err on the side of controlling too much. Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.
jordigh 9y ago
We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished. Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code. I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.
- mikegerwitz 9y ago
  > main maintainer was getting tired Would the project have had much development at all without the "helpful guy"? If the maintainer was too tired to even keep an eye on him/her, then it sounds like the project would have stalled without that help.

by ef4 9y ago

asdfasdfasd333 9y ago

Absolutely this. This applies to engineering at software companies as well.

Klathmon 9y ago

I completely agree, the only thing I still like to keep to myself (or to a very select group) is the ability to cut a release. If you want commit access, just ask. But I still want to validate releases that get pushed out to a bunch of people.

mjevans 9y ago
My policy is to never ask, and to only accept if I think I can be worthy of the work at the time (so I might accept at a later date if I feel I don't have the bandwidth today).
- Klathmon 9y ago
  And I tend to try and offer if i start to notice the name in a few issues or PRs.

zzzeek 9y ago

Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.

bartread 9y ago
Superficially, that sounds more like a release process issue than a bad commit issue.
nextlevelwizard 9y ago
How often is commit bad enough to require revert, yet made it through testing and got released?
- btown 9y ago
  Code style, inconsistent APIs, a feature that's barely tested by its own contributor, introducing dependencies on innards that were planned to be removed by an ongoing refactoring project, etc. So many ways contributions can go wrong.
  - diggan 9y ago
    All those things should and hopefully would have been caught when the PR was made, not after the commits made it into master.
    - btown 9y ago
      The entire context of this thread is that adding committers can introduce risk in the quality of accepted contributions. Building a trusted network of gatekeepers is hard.
      - nextlevelwizard 9y ago
        Just because stuff gets to master doesn't mean they get to the release.
  - snakeanus 9y ago
    > Code style How is that an issue in this day and age? Just run astyle or indent.

hacking_again 9y ago

> One or two good PRs is enough for me to give you commit bit on my repos. This has never yet resulted in abuse, and has brought in a many helpful co-maintainers. In addition, I find it's helpful to identify the really keen contributors and ask them privately see if they want to take on more responsibilities.

imhoguy 9y ago

"a bit of trust" this! Most often maintainers ego is the issue and too much control over ones baby project is the road to frustration and burnout. The way the power is shared and the shape of community structure is huge factor often neglected by tech-only focused maintainers/owners. There is a good piece of wisdom on social aspect of open-source in Social Architecture by Pieter Hintjens[0]. I recommend learning about his pov to anyone interested in open-source open-projects. [0] https://www.gitbook.com/book/hintjens/social-architecture/details https://www.gitbook.com/book/hintjens/social-architecture/de...

ngrilly 9y ago
Excellent read! Thanks!

ATsch 9y ago

A gitlab feature I miss on Github is "protected branches" and being able to add contributors that can only push to unprotected branches. This way you can give people access to the main repo while still being able to check code before it goes into master

lamby 9y ago
You can do this on Github with custom hooks etc. But yes.
- hnlmorg 9y ago
  That's potentially one way of doing it but Github does also have a specific feature for doing this literally called "Protected branches": https://github.com/blog/2051-protected-branches-and-required-status-checks https://github.com/blog/2051-protected-branches-and-required...
eb3c90 9y ago
You can do this now. $work uses github and has it so that a bit of code has to have be reviewed before it can be merged to master.
hnlmorg 9y ago
You can do this on Github. It's even called the same. Go to your repo -> settings -> branches and it's the 2nd item (Protected branched). I use this feature at work so I can confirm it behaves as expected.
- ATsch 9y ago
  Oh, great! I tried it a while ago and the setting was nowhere to be found!

j_s 9y ago

The Pull Request Hack | https://news.ycombinator.com/item?id=5357417 https://news.ycombinator.com/item?id=5357417 (March 2013) http://felixge.de/2013/03/11/the-pull-request-hack.html http://felixge.de/2013/03/11/the-pull-request-hack.html > Whenever somebody sends you a pull request, give them commit access to your project. I agree with requiring more accountability before granting the ability to create official releases.

ngo123 9y ago

> Most maintainers err on the side of controlling too much. Burnout can happen by working too much. It can also happen by too many discussions/politics if you give out commit rights like cookies.

jordigh 9y ago

We kind of did this with a project I was working on once. Someone was being helpful, main maintainer was getting tired, so helpful guy got full rights to the repo. He went on a several-year-long frenzy of activity, up to being a release manager, putting lots of micro-optimisations into the code and still being generally helpful until he got sucked up by Google and vanished. Sadly, lots and lots of little bugs and awkward design decisions crept through. Obscure ones, hard to find, and a coding style that tended towards obfuscation. Guy had a habit for assemblyish/fortranish code. I think the lesson learned is, sure, maybe give the helpful guy full access, but still keep your eye on them and encourage everyone else to do so too.

mikegerwitz 9y ago
> main maintainer was getting tired Would the project have had much development at all without the "helpful guy"? If the maintainer was too tired to even keep an eye on him/her, then it sounds like the project would have stalled without that help.