Openness of our discussions

This was originally posted by me in the dev chat, so context might be lacking a bit.

I also thought about the general topic of “openness and decision process” for a long time last night and do think we have a problem. The fact is that most of the contributions in the last months came from a handful of students from germany that meet in Mumble every evening and do stuff™. This leads to things being discussed in a small circle, even though I personally tried to involve the community (via this chat or issues) before implementing major changes.

A contributing factor to the “backroom discussions” might be a percieved “shouting into the void” aka the lack of responses when trying to discuss something with the “whole community”. I write “percieved” because community involvement might suddenly jump up if we force ourselves to discuss everything publicly.

After reading I came to the conclusion that we (yes, I do include myself in that) really should do better in discussing things in public. I welcome opinions on what the best place for “(technical) meta-discussions” is (either GitHub issues or Discourse come to mind).

I’d like to keep GitHub for the technical issues and suggest putting such topics (like this one already has been) on the Discourse.

I want to give a bit of a history about how it was handled before we started the overly active and quite successful 2.0 development:

The usual chain of events, to avoid the word “process” here, was to throw topics into the Matrix room, sometimes people had opinions on things, sometimes not. Followed by that, if things became clear, the implementation took place. Usually leaving PRs 24 hours open to allow everyone in any timezone to have a chance to react.

If the shout into Matrix ended up unhelpful, usually a GitHub issue (given it pre-dated discourse) was raised. Often this also already happened in parallel to matrix. Given how things are in free software, not always did issues get answers immediately. Therefore a lot of issues, where just hanging around, waiting for some bright mind to come up with a pleasant solution. If something rather urgent appeared or there were some ideas, but people refused to respond, I consulted individual community members who appeared to be able to contribute to those issues, and asking them for a second opinion.

This usually ended up in either solving the issue or concluding that the issue might also not being as important as it appeared.

One major advantage I see in this way is the ability for everyone to contribute, as the fragmentation of audiences is rather minimal and usually people who wanted to get a glimpse onto a topic were able to.

The obvious disadvantage of this way is that some issues are dragged around for months, because no one came up with a solution that one wanted to implement. Making it rather complicated to apply for the rapid development we see for 2.0.

My personal preference would be to drop both, the mumble sessions and the developer matrix room.

The mumble sessions, due to their synchronous nature, simply make it hard to impossible for all community members to participate even if they want. Also synchronous meetings are unsuited for any meaningful decision making in free software communities. Means working on an implementation using synchronous meetings is no problem, but making the decision that has a broader impact this way, is not really helpful. I recall this happening for example by the sudden decision to write a new client in react, which made some people unhappy at first, because they didn’t even see a chance to argue against it. (this was however somehow half way the outcome of a community call, not a mumble session)

The developer matrix room, seems to me to be somewhat a gatekeeper to open participation. While not uncommon among free software communities, it drastically reduces the reach of messages even without anyone, to my knowledge, complaining about a too “noisy” main community room. Also as with this topic coming up, that a lot of the topics are fluid between development and organizational topic, making it, the mentioned “backroom” for discussions.

All in all, I’m happy to see the discussion here and I hope we can figure out a more transparent way to communicate.

1 Like

The mumble sessions, due to their synchronous nature, simply make it hard to impossible for all community members to participate even if they want.

Yes. Deciding things via Mumble is problematic and we need to stop doing that (but, as I wrote, I already try to involve the community in discussions that come up in Mumble).

The developer matrix room […] drastically reduces the reach of messages

That is the point. :smiley:
At least in my understanding, the idea is that user support and “general chatting” are separated from development. If a user joins a chatroom with an ongoing discussion about a deeply technical topic, they might be “scared away”. Personally, I also enjoy the mental separation between a general and a dev chat.

even without anyone, to my knowledge, complaining about a too “noisy” main community room

Which might be because the main and dev rooms are separate?

I agree that we should advertise the dev room more (like mentioning it in our contribution docs), but I’m strongly against squashing the main and the dev room together. Many users are exactly that - users - and not interested in dev-related content.

I too think that a merge of both rooms would be undesirable

1 Like