Topics and requests: a hierarchy of rooms with ending sub-rooms

[mrsimpson]

Use case

Channels as implemented in RC, Slack, Mattermost and alike are content-driven multi-party discussions. However, what they are lacking is that they end once the purpose of the discussion has been fulfilled.
This is also what makes channels different compared to threads of the newsgroup-age. Of course, you can always leave a channel, but that won't stop others from continuing with new content there.

Consequently, content of a channel tends to become less coherent. This makes it difficult for newly joined people to understand from where it makes sense to read and in order to catch-up. Additionally, it is difficult to to use a channel as a reference when trying to refer to it as source of information.

Features

It should be possible to create a two-level-hierarchy of rooms with the following characteristics:

new room types

A topic denotes some area of knowledge. Multiple experts may personify this knowledge. A topic is represented as a (never ending) channel in which experts may discuss internally.

A request is a discussion between someone seeking information within a particular area of knowledge and the experts providing it. A request is comparable to a livechat-room with the difference that multiple persons may be joined providing information at once.
A request shall be created for a particular topic. All members of the topic shall be included into the request room. The topic shall prefix the request-room-name suffixed by a unique ID.
As a request serves a defined purpose, it should be closable. Once a room is closed, no new message can be added - unless it is re-opened.

Tagging

Both, requests and topics shall feature tags in order to find them more easily. When creating a request, the type-ahead shall also search in tags of topics in order to determine the proper topic

Additional properties

• If a channel is a topic, it shall be private. Reason: It shall serve as place for knowledge exchange between experts, but requesters shall create a new request (with an end) in contrast to simply asking in the topic channel itself.
• If a channel is a request, it shall be private. Reason: Not expose not-knowing to others - always-publicity might reduce acceptance

UI

Proposal:

Create new channel
  for topic |____|
  is topic ( )
  private (X)

If a topic is entered, the members-selection, read-only and "is topic" shall be hidden.

Authorizations

As usual, the creation and deletion shall be protected by authorizations.
Users shall be able to create topics, guests shall only be able to create requests.
A special read-authorization is not necessary, as the existing authorizations for viewing a joined channel suffice.
Adding users to both the types shall be allowed for all members of the rooms (standard for private channels, afaik).
Closing and re-opening a request shall be possible for all members.

AI integration

Closing a request shall trigger AI just like in livechat-rooms.

Configuration (optional)

• There shall be an option to enable topic-support
• Only of enabled, is_topic and for_topic shall be visible in the creation screen

Compared to threading inside a channel as in Slack

Current slack channels with threading actually support something similar (in contrast to the lightweight threading in RC) - but they have no defined end and referring to the threads themselves is not easily possible.

[pshute]

in contrast to the lightweight threading in RC

What lightweight threading do you mean? Channels?

I suspect your suggestion is too complex for a lot of people and would be better addressed with some kind of message tagging in the existing channel structure. I like newsgroup style threading, but it's so easily abused, and requires so much cooperation and thought to be properly useful that I think it got a bad reputation and we've ended up with the flat messaging that's common now.

[mrsimpson]

@pshute lightweight threading in Slack spawns a discussion from a channel.
With respect to abusing newsgroups' reputation: I personally think that this originated in long messages and full quotes as it is common in forums (just like we are discussing now :) ):
Due to the very asynchronous messaging, messages had to be long and as such tended to be not very coherent, but covered multiple topics in one post.
I believe that instant-messaging as we perceive it has some benefits to that.

[pshute]

@mrsimpson, I know abut the threading in Slack, but you referred to "lightweight threading in RC". Not sure what you mean there.

Yes, there was overuse of quoting in newsgroups. It probably contributed to the backlash that resulted in simple chat style applications like Rocket.Chat. However, without something to link parts of conversations together in a channel where there are overlapping conversations, Rocket.Chat users must resort to quoting or trying to respond quickly before part of another conversation is posted. They can also tag the name of the user they're responding to, as I've done above, but that doesn't work if that user is also partaking in another conversation in that channel at the time. That happens regularly in our team of just 4.

A "message tag" might be sufficient. RC's Reply function does this, but by displaying a quoted message. Instead it could display a uniquely coloured flag in both the reply and the message being replied to.

I still don't quite understand your suggested implementation. Are you basically suggesting the equivalent of short-lived channels for your "requests"? The terminology sounds like you're thinking of a very specific use case.

[sampaiodiego]

just adding a screenshot to show how others do this:

it's also very simple to use and manage.. you create a "category" then drag and drop channels into it. or you can use the "+" icon to create a channel inside of a category

[Sing-Li]

With scaled server configurations, the ability to create and manage subgroups will become basic requirement just to maintain usability. johnmberger and his group is one of our earliest community members deploying scaled configurations - and their solution as a PR has been referenced above -
#8873

[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.

#13843

[engelgabriel]

purpose of the discussion has been fulfilled.

@mrsimpson you have been right in calling it a discussion from the beginning