[skeeter2020]

bug reports and communication in general: If you've got a good summary/abstract more detail is always better. I don't know if I've ever had to talk to someone on my team about how they "over communicated" (not the same as TMI!). Make the receiver responsible for saying "OK, that's enough, got it!"

[edflsafoiewq]

Conversely I think you should generally write the smallest amount of text you can. It maximizes the chance someone else will actually read it.

[codetrotter]

I sometimes try to follow the journalistic reporting way of writing. (Not the clickbait style mind you.)

So I start it off with a few brief paragraphs of text explaining what I did, what happened and what I expected to happen. Each paragraph only a couple of sentences long.

Then below that I fill in with more details.

Of course this still means that if you glance at it you still see a lot of text and may not bother reading. But my hope is that if by chance the recipient does read the first few paragraphs then it will provide the necessary motivation to either read on or to begin investigating on their own.

[stjohnswarts]

It's best to do something like

1. config and versions

2. the bug (failure to see expected results

3. how to reproduce in as simple terms as possible

4. any data such as screen shots, core dumps, logs, etc