Build our community forum

Site Feedback
1

:wave: Hello markdown hackers,

As you may notice we have our community forum now. :tada: It’s hosted by our friends at Indie Hosters and will provide a nice home for all CodiMD users, developers and contributors.

Since I’m not too much of a forum person, I would really welcome your ideas, suggestions and wishes on how to use this Forum in the best way possible :slight_smile:

So please suggest some categories and topics that we should tackle with this forum. Share your knowledge and experiences about organizing a community forum and help to bring people together.

And since this is the first real thread in this forum, welcome to the forum :wink::sunny:

PS: This also means we look for someone in the community who wants to take responsibility and become a moderator

2 Likes
2

Ahoj Sheogorath, ahoj community!

For that we should ask the questions why we want to add a forum, while having GitHub (including an issue tracker) and a Matrix channel already.

This answers also the question what we want to achieve with this:
Involving more non-devs in the development by facilitating participation, while keeping the technical details on GitHub.

How can we achieve this with a reasonable information- and workflow

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.

concepts etc.
Model Forum Issue Pull Request
SemVer 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
IETF-like Request for Comments (RFC) Working Group discussion Implementation
Scrum Epic discussion Story/Task 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 :slight_smile: ):

Technical Workflow Draft

  1. Everything that results in a MAJOR or MINOR change (feature requests, breaking changes) MUST be proposed in the forum. (Labelled RFC)
  2. 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.
  3. 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 :wink:

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 :smiley: .
Nonetheless, this is just a draft for this guideline, not all questions are asked and participation is absolutely welcome.

Happy hacking!

3

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. :slight_smile:

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:

Platform Topics
GitHub Feature requests, bug reports
Forum (here) Community topics, support, …
GitHub Wiki Non-Release related content (e.g. an instance list)
Matrix interactive support, getting opinions, announcements (usually links to platforms above), offtopic chats, early access, …
POEditor Translations

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.

What do you think?

4

Alright, that is a proper solution. :+1:

Only mentioned it for a possible change in workflow.

The GitHub wiki is better for our use cases. Discourse Wikis are more suitable to discuss a single page IMHO.