To thread or not to thread. That is the question

In Canonical-specific work rooms, it’s generally a policy that the first message in a conversation should be a normal message, then the rest of the conversation should happen in a thread (at least, that’s the pattern I’ve seen). This is important for Canonical employees to be able to work in parallel without drowning each other out. This is in stark contrast to many of the community-specific rooms (most notably flavor dev channels), which seem to have a much more IRC-like “throw everything into one chatroom and hope for the best” mode of operation. These two ways of operating are fundamentally incompatible and result in confusion in some instances - someone used to the Canonical way of chatting might start a thread in the middle of a large IRC-style conversation and then get lost in the flow, while someone used to IRC-style conversation might send five messages in a Canonical-chat-style room and disrupt work on accident.

Each room’s admins are obviously free to set and enforce whatever policies they want with threading. However, for the rooms that are maintained primarily by the Matrix Ops team (Ubuntu Support, Ubuntu Discussion, Ubuntu Matrix Ops, and arguably maybe also Ubuntu Flavors, Ubuntu Development, and maaaaybe Ubuntu Release though I think that one isn’t under Matrix Ops jurisdiction), I think we should stick with one method of doing things so that we have the least chance of causing problems. Either we should require things to be done in threads, or we should require things to be done IRC-style, not both. Otherwise important chats will get lost or people will get sorely frustrated.

There are good arguments for and against using threads - some arguments for both sides are:

  • For threads:
    • Canonical employees are used to using threads since they have to in their rooms. Many of the most notable community members in Ubuntu are Canonical employees, so this represents a significant portion of our userbase that we want to support.
    • Element is the only client that really supports threads well (specifically Element Desktop/Web), but Element is also the only Matrix client the Matrix Council recommends, and other clients are basically unsupported (you can use them if you want but be ready to solve problems on your own).
    • Threads really do help keep a room from being too noisy, which can be of great value in highly active rooms.
  • Against threads:
    • We may have our recommendations about what Matrix clients to use, but let’s face it - people are going to use whatever Matrix client they want. juliank uses Fractal, irihapeti uses Nheko, eeickmeyer uses or at least used to use NeoChat, I’ve played with Nheko, NeoChat, and Gomuks, etc. Virtually every single Matrix client except Element handles threads horribly, even Nheko which is supposed to have support for them to some degree. Thus a threads-first policy makes life horrible for a substantial portion of our users.
    • Threads are just hard to follow. Doesn’t matter what client, even Element struggles with this. If you ping someone in a thread, chances are they will never see it because they won’t be able to even tell you pinged them, and even if they figure it out they might not find the thread you tried to ping them in. I had this happen to me just recently, and left rbasak without admin rights in a room he needed them in for multiple hours because I just didn’t see his ping.
    • Threads are hard to hold a large conversation in. Element seems to think that a chat pane the width of dining fork and a half is plenty enough room to hold a conversation in, when it’s really just not. Once people start writing large messages (and we have a lot of those kinds of people in this community, myself included), it becomes cumbersome to scroll through and read the conversation.

Ideas? Personally I’m undecided here - I don’t want to make life harder for Canonical people or end up with rooms that are too chaotic to follow along in, but as you can probably tell I really do not like threads personally.

Again, this is NOT talking about an Ubuntu Community wide policy. Each room should do with threads what it feels is right. This is just talking about policies for a subset of rooms that the Ubuntu Matrix Ops oversee.

5 Likes

This is a hard decision, as an Ubuntu Board Member I do not see any use for threads in that room but I am also trying to get into development and once the majority of devs move to matrix there may be a need to have more private conversations to keep the noise down.

I am fairly new to matrix of course and on irc if I needed to talk privately with someone I just opened a private chat so I do not see why we can not do that on matrix and get rid of threads all together that is just my opinion but I do not know that we should decide that for everyone.

4 Likes

I kind of consider a quote reply to be a thread. This is how threads are implemented in other services like Signal and RCS messages. Sure, there’s a little extra noise, but each message is clearly linked to some other previous one. IRC doesn’t have this option and can be kind of confusing because of that. As a hardcore IRC user, I’ve never had a problem with this, until it came to reading old scrollback. It’s just hard to follow. This solves the problem without any of the problem that Matrix threads create.

1 Like

TL;DR: Element threads are nowhere near as good as Mattermost’s, but they’re still better than replies, because they’re less noisy and at least they’re bidirectional.

Let me start off by stating this: threads in Element suck. They’re mostly useful to hide conversation away (which is useful to keep things sane).

Now, let’s compare to threads as implemented in Mattermost’s default clients[0]. There’s no concept of reply in MM, you only have threading. Answering a thread is silent by default (I think?) except for people involved in that thread, but you can manually subscribe to threads. Crucially, there’s a view of all threads you’re subscribed to, meaning you can log in and immediately see which conversations have new content (and with a decent width, too :wink: ). If you get highlighted in a thread, it’ll pop up in that view (with a proper high-priority). Oh, and if you really want to see everything that’s happening you can toggle a setting that show all thread replies woven in the main conversation[1].

With that UX, threads are great for semi-asynchronous communication, especially on busy channels with conversations happening on lots of unrelated topics, e.g. #ubuntu-devel.

With the Element UX, they’re not as great, because, well, again, that UX kind of sucks.

However, threads are still much better for the -devel/-release use case than replies or even straight normal posts, IMHO.

When in full steam, those channels have multiple parallel conversations that can span multiple days. It was bad in IRC, but at least you had a fairly high information density and sorting out the context is usually through HL prefixes. You can do the same in Element, except that information density is clearly not as high, even using the IRC mode. Using threads solves this, and presumably you should still be able to find a client that meshes thread answers within the main conversation IUIC.

Another problem of replies (that was already present on IRC) is that you can only trace them backwards. When reading an old message, because, say, someone highlighted your team during the night you can’t easily see if someone already answered it, you’ll have to read the entire logs to try and find replies.

[0]: Very relevant here because, as pointed out, threads are mostly used by Canonical folks and our experience of chat threads directly comes from MM. It’s actually one of the reasons we don’t use IRC as often as we should.
[1]: I just turned that on and even in my own team’s channel it was a horrible experience.

6 Likes