感谢分享这些背景信息，James！
总之，目前看来我们有五种方式表明一个话题已经告一段落，需要收尾。这样概括是否准确？
| 方式 | 位置 | 责任人 |
|---|---|---|
 Discourse Solved |
Support #installation Development #data-reporting Support > SSO | 话题所有者、@team、TL4 |
| fixed | Contribute > Bug Contribute > UX（适用于所有地方） | @team |
| completed | Contribute > Feature Contribute > UX | @team |
| delivered | Marketplace | 所有成员 |
 关闭话题 |
所有地方 | @team 及自动机制 |
这确实感觉种类繁多。我不确定为什么标签会有所不同。也许这样有助于用户分别浏览这些标签列表。不过，这些标签及其用途并不那么容易被发现。
「solved」标签很容易被发现，且在支持类话题中效果很好。我认为将其限制在支持类别中是合理的。在该类别中能够筛选已解决/未解决的话题很有帮助——不过我常常忘记使用那个下拉菜单，希望它在界面中更醒目一些。
fixed 仅用于 Contribute > Bug 和 Contribute > UX，表示某个 bug 或用户体验问题已修复。
completed 用于 #support、Contribute > Feature 和 #contribute:ux。之所以也用于 Contribute > UX，是因为用户体验类话题通常也包含功能请求。曾有一个话题 "Reader Mode" theme component feedback 位于 Contribute > Site feedback，但我已将其移至 Customization > Theme component，因为随着该组件的发布，它现在似乎更适合放在那里。
delivered 仅用于 #marketplace。
话题因多种原因被 关闭：
- Support 类话题在得到解决后，若一个月无新回复则自动关闭
- Marketplace 类话题无论是否标记为 delivered，若一个月无新回复则自动关闭
- 版主手动关闭话题
- 当话题已解决时
- 为防止继续回复（例如文档类或 release-notes 类话题）
- 作为管理策略，用于结束已失去建设性或已告一段落的讨论
一些可能的后续步骤：
- 为 #fixed、completed 和 delivered 标签添加说明，解释我们如何使用它们
- 创建一个数据探索器查询，生成类似上表的结果，但列出实际且最新的已解决/未解决、已修复/未修复、已完成/未完成、已交付/未交付的话题数量
- 创建一个数据探索器查询，列出在指定时间段内被关闭、修复、完成或交付的话题
- 在 Contribute > Site feedback 中创建一个话题，每周通过自动化方式分享上述查询结果
- 在此创建一个话题，提供一份关于如何收尾话题的简易指南，并组建一个团队按照该指南，按时间倒序逐步处理待收尾的话题列表