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.