where one can easily stay informed about current topics
and the effort of maintenance and moderation is low?
There may be further constraints, but prevent over-engineering is most likely one, so to boil it down:
Translations and documentation are quite obvious, Matrix should most probably only host non-permanent information, like a chat. But where do we draw the line between the others? Do we establish a strict workflow, which regulates which goes where and how it is related, providing the necessary clarity?
Based on the following conceptual draft I propose a solution below.
Introducing and discussing MAJOR or MINOR change OR clarifying whether something is a bug (PATCH)
Technical discussion with the mission (defined in the forum) to implement a MAJOR or MINOR OR reporting a bug (PATCH)
Implementation details related to an issue
Request for Comments (RFC)
Working Group discussion
Implementation (Epic, Story or Task -> master, Story or Task of an Epic -> branch)
TL;DR: Based on these models (and my interpretation and translation of those) I propose the following technical workflow (this is an RFC ):
Technical Workflow Draft
Everything that results in a MAJOR or MINOR change (feature requests, breaking changes) MUST be proposed in the forum. (Labelled RFC)
When a consent is found/decision is made, the topic will be labelled Approved and a issue is created, where the technical discussion MAY take place.
Potential contributors/assignees create a (work in progress, WIP) pull request referencing the issue, where small implementation details MAY be discussed. Once merged, the issue will be closed and the forum thread will be labelled Implemented.
Additionally (exceptions confirm the rule):
A PATCH SHOULD be introduced as an issue.
In case of uncertainty a chat in Matrix or a discussion in the forum, especially for non-devs, are welcome starting points, even for potential bugs.
If no automated solution is present, moderators SHOULD encourage authors to re-post their concern in the right location, assisting them if they refuse for whatever reason.
Non-technical discussions/topics of all kind (community related etc.) SHOULD take place in the forum. In other words: Post everything else in the forum
What are the negative labels? Should labels model the state, aka being removed? Is it an appropriate solution to subscribe those in the forum to stay informed? What can be automated?
I hope this is neither over-engineered nor off-topic. If we find a consent, we might create an issue to update the README.md and CONTRIBUTING.md .
Nonetheless, this is just a draft for this guideline, not all questions are asked and participation is absolutely welcome.
I don’t think we’ll have strict regulation. Our community is big enough to have things organized but small enough that we don’t need to enforce rules that much.
I also think that an RFC-based or a bigger change management process in general makes sense when you have full-time developers, but for us, we run all those things in our part time, for fun, and we don’t try to standardize things. So let’s keep our creative chaos.
For now I would like to keep Feature requests and bug reports on Github. While everything support and community related should take place over here. I agree with you that Matrix will be only for chat.
I think we may can put it like this:
Feature requests, bug reports
Community topics, support, …
Non-Release related content (e.g. an instance list)
interactive support, getting opinions, announcements (usually links to platforms above), offtopic chats, early access, …
I think we might consider to add the GitHub Wiki over here, as Discourse has a Wiki functionality, I just never used it, so not sure how well it works.
And yes, we should update the CONTRIBUTING.md soon. I think the README.md already got a good rework this week.