Clarification about the "be concise" section in the community standards guideline

Quoting the content of the relevant section in the community standards guideline

Constructive criticism and suggestions are welcome, but high-traffic forums do not generally have the bandwidth for extensive discourse. Consider writing a blog post if you feel that you have enough to say on a particular subject.

After doing some Git archaeology, I found that this is the commit (on Jan 16 2015) that added the community standards page to the website. The “be concise” section has been present from the very beginning.

While the recommendation makes sense for IRC/Slack/Matrix, where long messages might get in the way of other people’s conversation, I don’t see it to be a problem in platforms where a long message can be posted in a separate thread on its own.

The guideline predates the Julia Discourse/Zulip, and so the reason behind it might be outdated?

(Originally asked in this Julia Zulip thread)

The biggest problem, as I recall, tends to be someone flooding a thread (or github issue) with so many posts that it overwhelms all other voices.

1 Like

But that problem could happen with multiple concise posts instead a few long posts, and it could be described as a separate guideline “don’t flood a discussion thread”.

I was searching for such flooding incidents on GitHub, in But the search result contains mostly closed issues, not locked issues (due to controversy).

Conciseness is a huge asset in communication. We all have limited time and it can often be tough to figure out what’s happening within a large wall of text, and that’s true regardless of the medium/venue.

I think it’s also helpful to message that being concise is an appreciated value in this community so folks don’t needlessly see brusque responses as offensive.


But I think the paragraph I quoted doesn’t exactly say to not be verbose. Not along the line of this Blaise Pascal’s quote

I have only made this letter longer because I have not had the time to make it shorter.

Instead, it simply says, for a long post (maybe >1k words?), you should do it as a blog post. The 2 guidelines are orthogonal to each other. You can still have a long post where its point is described as concisely as possible.

I like the quote. It matches the intent of the guideline. We ask you to be concise, which means that you take care in expressing your question or position, and we create an expectation as @mbauman said that answers from others might also be concise.

You can still have a long post where its point is described as concisely as possible.

Yes that is very true, we would still ask you to consider the right forum for your post. That’s why the guideline doesn’t give a word-count. It is meant for you to take a breadth and consider the position of the reader. Is your post considerate of the readers time? Does your post come across clearly or did you bury the lede?

As an example, if I were to discuss my concern around implementation details in the runtime, I might write the context, history, performance experiments done etc up as a blog post. My goal there would be to educate and convince. Then I would start a discussion here around these points by concisely stating my conclusion and pointing to my blog-post.


You may have posted the original long content as a blog post, but the followup extensive discussion would still happen here on Discourse.

… but high-traffic forums do not generally have the bandwidth for extensive discourse.

I can’t tell if this means a series of long posts (each by a different person) is discouraged in general.

One example of a long post that I found elsewhere is from the Lean prover forum.

Anyway, the elaboration by @mbauman and @vchuravy are much clearer. It’d be nice if the guideline states the same thing explicitly, instead requiring me to read between the lines.