A lot of discussion happens in asynchronous online conversations nowadays. Most notably, public chatrooms, such as IRC, Discord, Slack, and the like.
This post is about a common behaviour seen in public chatrooms about technical topics, or focused on helping eachother on whatever the topic is.
In those environments, it's common to see a exchange like this:
[10:15] Alice: Does anyone here know C#?
[10:16] Charlie: I do!
[10:35] Alice: @Charlie, I have this problem so and so...
[10:36] Charlie: Yeah, you can solve it this way.
Or a bit more specifically:
[10:00] Bob: Hi! Anyone used Unity's feature before?
[10:20] Daisy: I have! How can I help?
[10:40] Bob: Cool, I was wondering if I can use feature like this?
[11:00] Daisy: Yes you can! Just do this and that and such.
Or, the classic one:
Evan: Can I ask about Unity here?
These messages, while sent in good faith by their posters, are not very useful for the community.
The main problem is that they require a synchronous reply and estabilish a conversation just to determine the actual question at hand.
Alice asks for C#, then Charlie has to reply, to only then Alice ask her actual question. This means that Charlie has to:
- Keep checking the chatroom every so often, to see if Alice replied (while in the example she did, sometimes people do not use @mentions at all)
- Stop whatever he is doing for a second time after Alice replies
This can also go on for multiple rounds sometimes, and it's even worse. Setting up a conversation also causes other people to be discouraged from posting in the chatroom during that exchange.
In this kind of chatroom, the best behaviour is to directly state your question in the original message, with as much detail as possible. It's perfectly fine to discuss, but respect other people's time
The correct form would then be:
[10:15] Alice: I have this problem so and so in a C# program...
[10:16] Charlie: Yeah, you can solve it this way.
Note how the total time spent resolving the problem decreased from 21 minutes to one! Alice didn't have to wait so much on Charlie's availability, nor did Charlie need to wait on Alice to extract the actual question.
I'm far from the first person to take note and criticize this behaviour, in fact this post's title comes from someone on the 3D RAD IRC support chatroom, where I learned about this concept early in my internet voyages.
And if you want a much more direct, if a bit snarkier, version of this post (and also much more shareable because of the cool domain name), check out https://dontasktoask.com/