Hey open source maintainers! We would love your feedback on the Sustaining Growth > Leadership & Governance article. We will leave this open for comments until Sep 1, 2016.
Does anything seem inconsistent with your experience? What is missing? Are there any other helpful resources on this topic?
Feel free to comment and discuss here, or even open a pull request to suggest changes.
"Meritocracy" will probably stir up some 😡/ :sob: so may be worth caveating or rewording to avoid that. I'd personally heard this described as "Those Who Do The Work Decide" or "Influence Relative To Contributions" or similar if that helps.
Otherwise I'm 👍 on all the content and feel I learned a few things. I'm looking forward to this being posted publicly.
Reading more about the NodeJS liberal model I wonder if it's worth adding some caveats that certain models are significantly easier if you have people paid to work full-time on the project.
@MikeMcQuaid it's an unfortunate term but it's also what the ASF officially uses. I agree with wanting to avoid 😡 though. Maybe we can add language there that clarifies this is their term, not ours?
Maybe we can add language there that clarifies this is their term, not ours?
Great idea 👍
This is a very tiny thing, but
BDFL: BDFL stands for “Benevolent Dictator for Life”. Under this structure, one
-person (usually the author of the project) has final say on all major project
-decisions.
+person (usually the initial author of the project) has final say on all major
+project decisions.
That is, in an open source project, there are many authors, but the BDFL is usually the initial person who kicked it off.
The liberal contribution model was pioneered by Node.js.
So, by the initial definition here
Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions.
This certainly has precedent before node. Rails operates this way, for example, if you stop working on Rails, you're moved to a "core team alumni."
The link to Rust's team page might also want to be a link to https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md or even https://github.com/rust-lang/rfcs/pull/1068 as it more directly shows off the move and how we did it.
I'd personally heard this described as "Those Who Do The Work Decide" or "Influence Relative To Contributions" or similar if that helps.
To copy a west wing adage... "Decisions are made by those who show up"?
Maybe we can add language there that clarifies this is their term, not ours?
Even a footnote that acknowledges that the term has different meanings across different industries could go a long way to show respect to those affected.
Maintainer
Contributor
Committer
To avoid confusion, do we want to crosswalk these terms with GitHub's terminology (where a committer is a collaborator and a maintainer is an owner)?
@peff: @bkeepers suggested you might have useful feedback here :)
I'll second the "meritocracy is a landmine" notion. If we use that word, we absolutely _must_ make some acknowledgement of its loaded-ness, or risk coming off as incredibly tone-deaf given the history that GitHub has had with the word.
Similarly:
The best part about open source governance is that it is shaped by the community!
It's also the worst part. :)
A lot of governance problems happen because there aren't any set rules, and everything is fine until one day it isn't. A troll shows up. One of the main contributors starts behaving badly. Money gets involved and some people get shut out (either intentionally or not).
I am not at all a fan of rigid rules or structure myself. But I worry that promoting a laissez faire attitude towards governance is going to end up criticized that it does not do a good job of protecting fairness, equality, and inclusivity. I don't even know if that's a valid criticism, but it seems plausible to me; in the absence of formal power structures, informal power structures will arise.
Not that I have a good answer. When we have promoted more structure (like codes of conduct, we've gotten criticized for that, too). I feel a little bit what we're damned either way, because there are so many opinions.
Collecting stats is another way to clearly find the contributors having the most impact on your project. Docker uses https://github.com/icecrime/vossibility-stack as a way to track what's happening all over all the projects. Also each repo is then tracked for who has had significant influence over the past few months. This is how the project decides who should be added as a maintainer, and on the other side of the spectrum who is close to not contributing over a long period of time and should "retire" or be added to project "alumni".
This helps people who want to become a maintainer have a reachable goal and not just depend on "who you know." It's all based off data and not just code contributions, helping answer issues etc as well.
@steveklabnik I think Node.js coined (or at least highly popularized) the term "liberal contribution", as far as I can tell...@mikeal, confirm/deny? Either way, I wouldn't want to steamroll projects that have followed the same model under a different name. I'll reword this.
@peff I like the idea of calling out that community can be the best or worst part. My goal with this article was to promote the idea that governance IS very important, to prevent tyranny of structurelessness, so if that didn't come across I'd def want to make it more explicit.
Re: "meritocracy", I'll make it clear this is the term used by the ASF, and maybe even include something that explicitly gives context/warning to using the term. Maybe I can find a good article to link to about why it's problematic.
@nayafia It _is_ a handbook section on governance, so I think that is a good step forward, and overall sending the right message. :) Maybe I'm just paranoid, but my years on the Internet have taught me that individual statements are prone to getting taken out of context and picked apart. Especially when it comes to contentious subjects.
Regarding meritocracy, it might be reasonable to link to http://geekfeminism.wikia.com/wiki/Meritocracy. Leaving aside whether there are articles with better content or not, I think the Geek Feminism wiki is probably a good central point to say "some people do not agree with this term, and here's a jumping off point for learning more".
@peff perfect, that's the kind of link I was looking for. thank you! :heart:
This section is the only one (other than legal, which will probably be split into a FAQ, see #82) in which the headings are questions.
Maybe they should be converted to non-questions, or longer ones also split out into a FAQ?
RE: fiscal sponsorship, Open Source Initiative will do that for "non-code" open source projects such as Open Hatch and Snow Drift. May not be worth mentioning seeing as this handbook is really speaking to open source software projects, but I'd be remiss if I didn't at least point it out ;)
Closed per #98.
Most helpful comment
"Meritocracy" will probably stir up some 😡/ :sob: so may be worth caveating or rewording to avoid that. I'd personally heard this described as "Those Who Do The Work Decide" or "Influence Relative To Contributions" or similar if that helps.
Otherwise I'm 👍 on all the content and feel I learned a few things. I'm looking forward to this being posted publicly.