proj-oot-ootCommunityNotes1

"

Let's say Bob Noob is trying to do X, and you can't do X in Clojure. There are friendly/welcoming ways to address the question, and then there are hostile ways.

Examples of friendly answers:

Examples of hostile answers:

Note that I haven't posted on the Clojure list, so none of this has happened to me -- I'm just observing what I see is a really negative pattern.

Hopefully this makes it clearer what I mean by saying Yes. I mean this:

   "Yes, there's a solution for you!"

" -- Steve Yegge, https://groups.google.com/d/msg/seajure/GLqhj_2915A/SMBHSMUGXBQJ

---

" MINSWAN

One interesting thing that surfaced in the debates is that while some describe the Clojure community as “incredibly friendly and helpful”, others describe it as hostile. Well, which one is it? Again I think it’s interesting to compare and contrast with the Ruby community.

From my experience, the average interaction on Clojure’s Slack, mailing lists or Github issues is polite and friendly. I see people tirelessly and patiently answering questions in the #beginners channel and elsewhere. People really want to help.

And yet it’s a very different vibe from what I see in the Ruby world. There people really go out of their way to be nice to each other. Github issues are accompanied by a bit more elaborate explanations, some emoji or animated gifs, because it’s a low bandwith medium and you really want to make sure the human on the other side doesn’t take things the wrong way. A phrase that was popular in the early days was “MINSWAN”, “Matz is Nice So We Are Nice”. It’s something that deeply permeates this community, it’s part of what made Rails Girls such a huge success, and it’s why I still love going to Ruby conferences. It’s a vibe that’s hard to beat.

There are trolls in Rubyland too, but they get called out immediately. There is very little tolerance for less than friendly behavior. Virtually every conference and meetup has, and enforces, a Code of Conduct. Being welcoming, especially to beginners, is an essential part of Ruby’s DNA. How to be and remain open and welcoming is an important part of the discourse.

Clojure is different, it’s a mixed bunch. There are old-school lispers, converted Java programmers, people coming from other dynlangs like Ruby or Python, and they all carry different expectations. If you’ve been active in open source for more than a decade you know that a thick skin was a basic requirement. Harsh interactions were par for the course. People do what they are used to, and without a guiding principle like MINSWAN it’s harder to call people out and hold everyone to higher standards.

In the Clojure world, as in Clojure code, brevity is considered a feature, but there’s a thin line between being concise, and being curt. People still try to be friendly and nice, but the dial isn’t turned up all the way to 11. This is painfully true when it comes to the official docs, which seem to be written for machines rather than humans, it shows in the error messages, and it shows in many small online interactions.

Languages that draw a younger, more homogeneous crowd: Elm, Elixir, JavaScript?, seem to be better at prioritizing the humanistic aspect. Both in the affordances of the software (Elm’s famous error messages), and in person-to-person interactions. I think we can, and should, take a leaf out of their book. "

---

i feel like Rust has issues due to its community hierarchy being too flat. Rust has a core team, and it has other teams with leads, but the core team has no lead, and the core team "does not make decisions that fall under the scope of one of the other teams". Rust is said to be becoming a rather large language, and i wonder if perhaps a bit of design-by-committee crept in due to their flat group structure. Also, Rust recently had a constitutional crises when the mod team resigned in protest of being unable to enforce the Rust Code of Conduct on the Core Team. The resignation suggests to me: (a) the governance system was underspecified, (b) either the governance system is very formal, and it was too complicated because this wasn't noticed/fixed earlier; or it has informal elements but the group's informal power structure wasn't able to resolve the issue, and also the length of time before the leadership issued a public responding communication (25 days) suggests that the power structure is too diffuse/flat, because that means that a long consensus-building process occurred in a situation where a quicker response would have been desirable.

i think a benevolent dictatorship would be better for an open source programming language project. In that setup, there is no separation of powers, there is only the executive power, which wholly resides in the Benevolent Dictator (B.D.); the mod team is not like an independent judicial branch, but rather an arm of the executive who report directly to the B.D.; and the other design and governance team members do not serve as an independent legislature, but rather they serve an advisory function to the B.D.

i would also have a core team, but the core team's scope would be everything, not just those things not covered by any other team or which are contested between multiple teams (also, recall that the core team's decisions are only advice to the B.D.).