ChanScout论坛话题与子频道拆分：构建 Discord 式社区中心
话题功能把一个群组拆成共享成员身份的多个独立对话，各自拥有未读计数、通知设置、置顶消息和链接。本文讲解话题真正解决的问题、何时不该启用、如何判断你的群组是否适合，以及启用时的注意事项。
话题功能把一个群组拆成共享成员身份的多个独立对话，各自拥有未读计数、通知设置、置顶消息和链接。本文讲解话题真正解决的问题、何时不该启用、如何判断你的群组是否适合，以及启用时的注意事项。
话题把一个群组变成一组共享成员身份的独立对话。每个话题都有自己的未读计数、自己的通知设置、自己的置顶消息和自己的链接。
这个功能很好。人们使用它时犯的错误是统一且可预见的：他们过早开启，创建十一个话题，结果原本一个热闹的房间变成了十一个安静的房间。本步骤讲的是话题真正解决什么问题，以及如何判断那是否是你的问题。
完成本步骤后你将能够
- 说出话题一开启，成员那边立刻会发生什么变化。
- 判断你的群组是否存在话题所针对的问题。
- 从正确的话题数量开始，而这个数量非常少。
- 在不退出社区的情况下静音某一个对话。
实际会发生什么变化
在大型群组的设置中开启话题，会一次性改变所有人的房间。成员打开时不再看到一串消息流，而是看到一个话题列表，然后选择其中一个。
此前的一切都保留在一个“综合”话题中，该话题也收集关于成员加入和离开的系统消息。什么都不会丢失，也不会有人被移除。
随之而来的这些特性才是值得这么做的原因。每个话题都有自己的未读标记，因此一个热闹的角落不会再让整个房间看起来都是未读。每个话题都可以单独静音，这是最有价值的一个结果。每个话题都有自己的置顶消息，因此一条公告会停留在它所涉及的对话上方，而不是在一个栏位里与其他三条争抢。而且每个话题都有一个链接，这意味着你可以把某人指向一个讨论，而不是指向一个房间。
还有一种视图可以把所有内容重新压平成一个带标签的时间顺序流，供偏好那种方式的成员使用。在宣布变更时值得提一下这一点，因为有些人强烈偏好扁平视图，否则他们会以为群组变得没法用了。
四个群组，以及话题是否有帮助
问题不在于规模。而在于不同的对话目前是否在互相破坏。
两个线程相互冲突
一个繁忙的对话
公告与聊天
一个全新的社区
两个对话不断互相打断
有人在讨论一次发布，同时另一个人在求助，双方都在滚动略过本该给自己看的内容。成员们已经开始为改变话题而道歉。这正是话题为之而生的情形，也是唯一一种开启话题能可靠地改善局面的情形。
要寻找的信号不是消息量，而是交错：两段各自连贯的交流被当作一段不连贯的消息流来阅读。如果你能用一句话说出这两条线索，你就有了适用场景。
只创建这两个话题，其余一切留在综合话题中，然后观察两周内会发生什么。需要自己空间的线索会自己显现出来。
两个有名字的对话在互相破坏，正是话题所解决的情形。创建两个话题，而不是七个。
只有一个对话，而且消息量很大
热闹不等于纠缠。一个四百人都在讨论同一件事的房间是在正常运转——虽然吵闹，但在运转。把它拆开会得到几个各自只有四分之一活跃度的房间，而对话经不起分割。
应对消息量要用不同的工具。第 055 步中带提及例外的静音能让成员留下来而不被打扰。第 060 步中的发言间隔能减缓洪流而不把它打散。第 042 步中的归档能让人们保留这个房间，而不让它一直待在列表顶部。
如果你拆分了一个热闹的房间，而话题们变得安静，那不是配置问题。这是只有一个对话的证据，正确的应对是重新关闭话题，并为这一周道歉。
消息量大不是混乱。拆分一个活跃的房间会得到几个死掉的房间——应该改用静音和频率限制。
公告总是被聊天淹没
这是一个真实的问题，而话题是它的次优答案。一个用于公告的话题是可行的，成员可以静音讨论同时保留它——但任何有发言权限的人仍然可以在里面发言，这种分隔是一种约定而非规则。
更强的安排是第 075 步中的频道加关联讨论组。在那种形态下，只有管理员可以发布，每条帖子自动拥有自己的评论线程，只想要公告而不想要对话的读者干脆不加入群组。
如果社区确实是对话式的、公告只是偶尔出现，就选择话题。如果你定期向一个以阅读为主的受众发布内容，就选择频道安排。
话题按约定分隔公告；频道按权限分隔公告。根据你实际发布的频率来选择。
你在搭建新东西，想让它有条理
这是这个功能造成最大破坏的地方，而背后的直觉完全合理。有人创办了一个社区，提前规划，搭建出一个繁荣版本所需要的结构：自我介绍、支持、闲聊、资源、公告、反馈。
然后三十个人来了，发现六个空房间，哪里都没有对话。空荡会被解读为被遗弃，没人愿意第一个在贴着别人计划的房间里发言。
从扁平开始。一个房间，所有内容都在一个地方，直到出现一条确实在妨碍另一条对话的线索。跟随实际对话而产生的结构才是人们会用的结构，因为它是根据人们已经在做的事情命名的。
不要在对话存在之前就建好房间。一个空话题比没有话题更糟，而一个新社区承受不起看起来荒无人烟。
如果你确实要开启它
有四件事能让过渡顺利，它们大多关乎人而非设置。
提前宣布，而不是事后。成员打开应用，发现熟悉的房间被一个列表取代，如果没有一句解释，一部分人会认为出了故障。说明正在发生什么、为什么，以及扁平视图仍然存在。
从两到三个话题开始。你随时可以在一分钟内添加更多。你很难从一堵空房间的墙中恢复过来，因为它留下的第一印象会一直存在。
按人们的说法命名，而不是按分类命名。“求助”胜过“支持与故障排除”。短名称在实际上也很重要，因为列表是一眼扫过的，长名称会被截断。
把地图放在综合话题里并置顶。一条消息说明每个话题的用途。第 047 步中单一置顶索引的做法在这里直接适用，它决定了成员是在选择话题还是在猜测。
现在试一试——五分钟
四个步骤，第一步是决定到底要不要做任何事的测试。
- 读一遍你群组里忙碌的一天，说出其中的线索 如果你能写下两段交错的对话，话题会有帮助。如果一切都只是一段对话，那就不会有帮助。
- 加入一个已经在使用话题的社区 看看有多少个话题，其中有多少是活跃的。这个比例通常很有启发性，而且比在自己的房间里学到这一课代价更低。
- 在你所属的某个地方静音单个话题 这是成员一侧的好处，亲身体验比读到它更有说服力。
- 如果你要开启它，先写好公告 两句话：正在改变什么，以及扁平视图仍然存在。先发布，再做更改。
每个话题都有一个地址
话题可以被直接链接，这是一个小功能，但有三个真正有用的应用场景。
新手引导。与其告诉新成员某处有一个求助话题，不如直接发送链接。在一个有十几个话题的社区里，说出一个地方和指向它之间的差别，很大程度上决定了对方是否会到达。
置顶地图。第 047 步中描述的索引在这里尤其好用：综合话题里一条置顶消息，每一行是一个带标签的话题链接。成员读的是列表而不是逐个点开名称，而你维护的是一条消息而不是一个结构。
在群组外回答。当有人在别处问你一个社区已经讨论过的问题时，一个话题链接会把对方送到那段对话，而不是送到一个还得自己搜索的房间。
两个实际限制。指向私密群组的链接只对成员开放，这通常正是你想要的——它不是向外部人士展示某个话题的方式。而且它指向的是话题而非话题中的某一刻，所以对于某段具体交流，第 047 步中的消息链接是更精确的工具。
这个阶段的常见问题
启用话题后，现有的对话会怎样？
它会保留在综合话题中，综合话题成为众多话题之一。什么都不会被删除，搜索仍然能触及全部内容，第 045 步中的媒体标签页继续覆盖整个群组。成员不会失去任何东西——改变的是新消息的组织方式，而不是已存在的内容。
成员可以创建话题吗？
这取决于你设置的权限，而默认值值得想一想。允许任何人创建话题适合人们自我组织的社区；它也会产生为单个问题而建、然后永远空着的话题。许多房间采用的中间路线是把创建权留给管理员，并邀请人们提出请求，这只需一分钟，还能让列表保持简短。
话题在频道中能用吗？
不能——它们是群组功能，因为它们组织的是对话。频道按设计就是单一消息流。频道的对应物是第 075 步中的讨论组，每条帖子有自己的评论线程，或者如果内容确实独立，就干脆再开一个频道。
我可以重新关闭话题吗？
这个设置可以改回去，改回去会让群组回到单一消息流。无论朝哪个方向，都要把它当作一个需要宣布的决定，而不是可以悄悄试验的东西，因为两个方向都会在成员打开应用的那一刻改变他们看到的内容。如果你不确定，代价更低的试验是创建一个话题，把其余对话留在原处。
多少个话题算太多？
实际的限度是你的成员不用滚动就能看到的数量，而在手机上这个数量并不多。超过之后，列表就不再是地图，而变成一个没人读的菜单。一个好的测试是每个话题本周是否都有消息；没有的要么是命名不当，要么从一开始就不是独立的对话。
这会让我的群组像其他社区平台吗？
结构上看起来相似，而这种比较值得稍微抵制一下。那些平台假设人们整天坐在一个常驻窗口前；Telegram 假设的是口袋里的一部手机和以个位数计的通知预算。这就是为什么本步骤中的静音行为比组织方式更重要，也是为什么在别处算适度的结构在这里会显得沉重。