Continuing the discussion from Organisational applications sitemap:
Right now I want to focus on the different communication channels we have adopted and how to make the best use of them without getting into cluttered overlap. In the future I’d like to get into the fundamentals of civilized discussion as well, but that’s lower priority right now.
Primary communication channels
Chat has a lower bar to entry than most other communication platforms. That plus the immediacy of live chatting makes for a great onboarding experience. There are however limits to how far up this can scale:
“where’s our invoice template again?”
“I need fresh eyes on this weird query”
“welp, I think I just broke something”
Servers are on fire!
urgent email was just received!
While social chatter is a rare occurrence on a forum, this is the norm in chat, and it happens in every room, not just a designated
#off-topic channel. This is a good thing.
The asynchronous nature of a forum community effectively lowers the bar about as far down as it can go. You’ll get a much greater diversity of input if you solicit feedback from anyone who’s available some time in the next 24, 72 or 168 hours as opposed to right now.
Communities of scale
Hundreds or even thousands of people can discuss an equal amount of topics simultaneously on Discourse without getting disoriented because (1) discussions are broken up into logical topic blobs and (2) long-form input is strongly encouraged over rapid-fire back-and-forth debating.
Knowledge storage & distribution
The relative permanence of a Discourse topic makes it a suitable storage of knowledge. It acts as a staging ground for any information important enough to be incorporated into the official manuals, meanwhile holding on to all that other information that was never quite important enough to be turned into structured documentation, but plenty useful to many none the less.
Civilized discussion by means of slower writing & thinking
Unlike in real-time chat, on a forum the expectation is that you’ll get a reply within a few hours or even days after posting; there’s very little urgency on a forum. The lack of urgency plus longer form writing lends itself better to System 2 thinking.
Feature discussions (tentative policy)
The general rule of thumb is that GitHub Issues is best for things that have a definition of “done”: they can be fixed, added, resolved, have a stake driven through its heart or otherwise laid to rest. For things where there isn’t a clear goal or end state, where you want to debate theory, or ask questions Discuss and the Atom Slack are the way to go.
Anything that seems to not be working as intended should be broken down in Issues.
Quite self-explanatory. PR discussions are best kept on GitHub