How to avoid humiliating newcomers: A guide for advanced developers

Also, it is possible to communicate reality of programming and "right mindset" without loosing control in the process.

Community - Fully open to discussion and contribution from everyone, decisions are made collectively and contribution / support responsibilities are shared by all.

Committee - Open to input, but decisions are made by the project leadership. Leadership is voted on by the community and provides support and contribution guidelines.

Ownership - There is a project owner or co-owners that make all decisions and offer support if available and set guidelines on contributions.

Visible - Open source in the sense of being transparent or usable by others, but little to no support offered and contributions may not be accepted.

I think many people think they're walking into a Community project when it's really a Leadership, Ownership or Visible project and feelings get hurt. Much better to set expectations early on in the README.

But the article here kind of glosses over the reality of the hard part: the low quality questions. The "please help me get started"; the "how do I get accepted"; the "please review my PR".

It's all well and good to say, hey, take a step back! Be nice! Don't respond when you're angry! But this is not the reality for an overwhelmed open source organization---and let's face it, most popular projects are completely overwhelmed. The reality is that to wake up every day to countless new issues and pull requests and other demands on your time is absolutely soul-sucking, and after years and years of this it grinds you down and leaves you with resentment and disappointment, and that's just absolutely not great for anyone.

I don't necessarily have any rebuttal to what the author is saying, and I think the intentions are great, but I think it's also important to point out what reality is for people who are trying to build community and help: everyone slowly burns out doing it. It's like social work.

(food for thought: Github has made this problems orders of magnitude worse for organizations, because lowering the barrier to entry means now anyone who doesn't know where to start can open an issue and clog up a bug tracker in just a few seconds, and anyone who thinks they can write code can open a low-quality PR in just a few minutes, and this is more to do for the maintainers...)

> Committee - Open to input, but decisions are made by the project leadership. Leadership is voted on by the community and provides support and contribution guidelines.

> Ownership - There is a project owner or co-owners that make all decisions and offer support if available and set guidelines on contributions.

Committee is the Debian Project, which has explicit governance and formal process, correct?

Ownership would be the BDFL model, like Linux or Python or most other projects I could name. Linux breaks down into subsystems, each of which are owned by a specific person, so it's a recursive form of the Ownership model.

I can't think of any project using your Community model off the top of my head.

> Visible - Open source in the sense of being transparent or usable by others, but little to no support offered and contributions may not be accepted.

I think this should have a different name, to make sure people don't confuse it with the non-OSS Viewable Source licenses some companies use: You can see the code, but you can't fork it and distribute modified versions.