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.
