3 ms·

This is a super mature, nuanced post so thanks for that. > It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contrib

This is a super mature, nuanced post so thanks for that. > It used to be that you might kick-ban someone from a channel or /dev/null their mailing list contributions. But if they made a technically meritorious merge request via SCM the contribution would still get due consideration. Even assholes can be good programmers, after all. That always felt healthy & mature to me. Finding a way to protect the masses from assholes without exiling the asshole always felt like a sign of good community stewardship. It's something I strived to do in communities I moderated. To some extent I think this is because GitHub doesn't offer the same tools that running your own mailing list would. A mailing list can do what you said, /dev/null ML contributions while still letting patches through. That's not something you can do easily in GitHub. > I guess if an OSS project is just a way for companies to commodify complements and for contributors to get jobs, then treating it like a Fortune 500 all-hands makes sense. Rust has a pretty friendly community (from what I've encountered at least), but a lot of its core stakeholders do have a lot of corporate obligations, and many of them Rust related. It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job. > I wonder how much of the conflict around CoCs boils down to this split in people's perception of what OSS projects are. Github is part of it, but in general I think a lot of today's OSS projects don't have a strict separation of "community" and "code" in the way that projects in the past used to. Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation, and that older tools like mailing lists are cumbersome enough to maintain that newer developers don't actually explore using them very often.

throwawaygh 5y ago
> [Moderation is] not something you can do easily in GitHub That seems like a pretty significant design flaw :( > Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation [between "community" and "code"] Indeed, this makes perfect sense. > It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job. Yup, totally fair and makes sense.

throwawaygh 5y ago

> [Moderation is] not something you can do easily in GitHub That seems like a pretty significant design flaw :( > Part of that is modern tools (Git forges like Gitea, sr.ht, etc) don't really enforce that separation [between "community" and "code"] Indeed, this makes perfect sense. > It makes sense to me that the Rust community would be more interested in treating interaction with Rust like a corporate project instead of a hobby club given that many of them are hacking on Rust for their actual job. Yup, totally fair and makes sense.