Threads vs Discussions

[engelgabriel]

We have decided that was better to delay our v1 release and get the Threads done properly than get the feature out the way it was initially implemented on the develop branch. We have "rebranded" our current implementation of Threads to Discussions (was it creates a new room type) and will implement Threads exactly the same way as Slack does.

In our vision there are 2 different use cases on how to break out of the main conversation: one very easy and organic, with a single click for small side talk, and other, much more structured, that creates a new conversation with its own life cycle.

We have tried to have a single solution for both, and as a result, no one was happy with it.
So we have given up on having a single approach for both use cases and will implement both: the Slack-like industry standard and our brand new one, called Discussions.

They will have totally different data models:

Discussions
Are basically new sub channels that inherit permission from the parent channel and have its creation announced on the parent channel.

Threads
Will exist on the same channel. They will replace/enhance the reply action we have now, but add the parent message property to the messages, so they can be displayed on the sidebar.

Both these features will be toggleable. e.g. turn on only threads but not discussions.

[engelgabriel]

#13664

[mrsimpson]

@engelgabriel I am kind-of afraid to write this, but I don't really see the difference in the two types.
I understand that you want to implement the "industry standard" and I appreciate replacing (quoted) replies - but I don't understand what makes "your" "threads" different from "discussions".

The reality captured

Looking at the "real world", what happens is that people talk about a topic and at some point in time, questions arise or details need further clarification. They drift off, finish the side-topic and come back to the plot. Sometimes, they discover that the side-topic takes too much room or that they need another expert joining - and leave the side-topic without finishing it.
Remark: Of course, I know a lot of examples where people never come back to it, but this is not mainly the subject here ;)

As an engineer, I'd phrase it like that

• If a new topic arises in a dialogue which needs further detailed discussion, every participant should be able to spin off a new dialogue ("thread"). Messages in this thread should not be visible in the origin dialogue in order to keep it coherent.
• If a user is allowed to participate in the main dialogue, he should also be able to read and join the thread at any time.
• Once the purpose of the thread has been resolved, it should be possible (for the starter of the thread/every participant in this thread) to close it, to indicate that everything has been said.
  -At any time, the participants of a thread should be able to add every person they know to join the thread. This "expert" should not be allowed to see the parent dialogue unless he's already a member of it.

In my opinion, you can replace the word "thread" with "discussion" and it would still be true.

Technically

The tricky part imho when it comes to lightweight (Slack-like) threading is, how to handle the notifications, how to make users recognize new messages in a thread (in which they may not even participate).
In Rocket.Chat,

• notifications come from subscriptions
• A subscription needs a room
• A room needs a name

This is what you don't have if you just reply to a message. Also, you can't separate members of thread and parent room without a subscription. Therefore, when I implemented the threading which now if in 1.0 beta, I decided for the sake of simplicity (and low footprint on the core) to fulfill the technical needs and visualize the thread as any normal room. This is particularly hand on mobile, where lightweight threading is even harder to visualize.
But: Imho, a lightweight display is absolutely a plus for many users. In #13394, I therefore commented where I consider the tricky parts to be and encouraged to build an alternative visualization based upon the current model.
I consider it a decision by the admin or even a single user how he prefers a thread to be visualized. I can even very well imagine that you can switch from an inline thread to a full-size view, in which you have all the controls such as the members list.
=> It's "only" UI, imho.

I really don't see what the characteristics of the "discussion" are which make this a new feature. Kindly elaborate, because I am very sure you've got something in your head which makes you very convinced ;-)

[khaledalyawad]

I raised another PR for threading #13805

[geekgonecrazy]

@mrsimpson I struggle with this one...

Chat is a weird mix of async with bursts of sync depending on the person or group. Because of this I think these two different ways of approaching forking from main topic make sense.

---

I think in the original thread issue I said I didn't see the point in threads. 🙈 Even when i've been forced to use slack to communicate.. It just feels weird and un-natural to me to use them seriously and heavily. But the discussions implemented actually make sense to me.

One really cool application for discussions is creating a discussion for a meeting. This allows a fork or branch off of the main channel to have the meeting. Clearly label the discussion. Start a jitsi meeting directly in the discussion. Everything self contained. Fantastic for archival. I found that the little extra conversational stuff was much easier. Because we didn't have to think about "what channel do I share this link i'm mentioning?" Everything just naturally dropped in the room I was having this meeting in.

So real time or async kind of your choice. But can span on with much longer focused conversation.

Threads on the other hand... Kind of feel like the equivalent of clicking reply and maybe having 3-4 replies and that's it it dies. Imagine the cleaner version of those nested reply's one had to use prior to threads or discussions.

[mrsimpson]

Dear Aaron,

it’s easy to imagine threads as a cleaner version to replies. In fact, I always thought that replies should be fully replaced by some kind of threading, I could not agree more on that. However, I am reluctant to see threads and discussions the way you describe them as separate entities.
Once somebody replies to a message, he starts something new: he starts a side chat related to one aspect of the message.
How long this side chat maybe, depends on the very topic - and the persons involved. And it may evolve. A conversation may start with “anybody coming for lunch” and after some replies, it continues as a general discussion about what the general consensus related to food is.
I can very well imagine a “thread” turning into a “discussion”. Also I don’t see a difference related to their life cycle. Thus, I am very sure they should be the same entity which is only visualized differently.
Even the same side chat could be displayed in the tab bar initially with an option to “pop it out”, opening it in the main view.
This would allow deep linking of a thread and add the ability to invite others to it without having them join the main conversation.

Verdict: don’t introduce another model, it will only add complexity - both technically as well as for the user.

_{Sent with GitHawk}

[engelgabriel]

@mrsimpson I really appreciate your feedback and point of view. You've managed to keep me awake at night a few times, pondering about the right way to move forward. In the end, I've got tired of trying to guess how exactly people will behave between the two features, so we planned to implement both approaches with some clear distinction between them and take this conversation about discussions/threads to our broader community.

You maybe be right and I think there is about a 50% chance that you will tell us "I've told you so" in the future when we merge both data models together, but for the v1.0 we will take a gamble and experiment with both.

[mrsimpson]

You are the maintainer, you are running most of the development. It’s your choice 👍
I don’t think I’ll have to tell you “I told you so”, you’ll recognize this yourself.
Still, I opened #14016 to get this integrated on the process layer

_{Sent with GitHawk}

[wreiske]

I'd like to see the discussions look more like discussions...
Check out https://help.github.com/en/articles/about-team-discussions

I noticed a lot of Rocket.Chat's messaging UI already looks like github team discussions.

Basically, replies would be under the top post in the discussions, allowing you to react, pin, etc the top "discussion"

[Drexl]

I'm very satisfied with the current split implementation of discussions/threads. It's exactly what we were looking for.