非常感谢您花时间在此分享您的经验。这也无疑为这次讨论注入了新的活力。
我很乐意与您进一步探讨，您也欢迎在此分享更多内容，但仅凭这篇帖子目前已经非常有价值了，所以谢谢您。
是的，我们当然重视让 Discourse 足够灵活以满足各种不同的用例。尽管如此，我们认为我们可以采取一些合理的方法来降低复杂性。这里有一些容易实现的改进，可以简化一些不必要的复杂之处，只需投入一些直接的时间和精力。@bloomexperiment 分享的想法是我们正在考虑的这类事情的另一个例子：
就我而言，我一直在思考非常类似的事情。
我们在最近关于用例的研究中（重新）发现了一些事情：社区并不适合所有情况。
将部分设置从“整个网站”设置转移到网站内较小的空间（群组或类别，或两者的某种组合）的设置，可以帮助解决这个问题。一个给定的社区可以有一个用于更多社交内容的区域，另一个用于处理项目，还有一个用于回答支持问题。
这也能让社区进行更多的实验。
当然，我们可以在您发起的主题中继续讨论，但想先在此处承认这一点。
感谢您花时间分享一些您认为值得改进的方面，以提升 Discourse 社区成员的整体用户体验。@lindsey 和之前专注于聊天功能的团队现在正在更广泛地关注这个领域，您在这里列出的内容与他们开始更仔细研究的内容有很多重叠之处。
感谢您强调这一点。这也是我们最近重新审视过的事情。除了文明讨论，我们还特别重视让社区能够从他们的对话和集体创造的内容中获得持久的价值。
很高兴听到您的见解 @oshyan。我们肯定会继续投入，让 Discourse 成为人们真正 渴望 使用的东西（无论是管理员还是社区成员）。我们知道这里还有很多工作要做，而且永远都会有！
我们偶尔也会讨论这个问题。有时我认为 Discourse 更普遍地被视为一个_沟通平台_。我们自己也将其用于协作，并且总是乐于看到类似这样的主题：Why you should use Discourse internally for your company/team instead of Slack (4 years use case)
一个有趣的切入点是扩大社区本身的价值。@HAWK 最近做了一个关于使用 Discourse 进行协作的精彩演讲，将其定位为建立内部社区的价值。
如果您还没有机会观看，我强烈推荐观看。
（几周后，她还将在Running Remote大会上，在葡萄牙讲述一个类似的故事）。