如果您能发起一个#site-feedback主题并对此进行一些阐述，那就太好了。 
我们有很多网站将一个分类用作知识库，我们自己也是如此，如果您有任何想法或反馈意见，我们随时乐意改进。
谢谢。我只是想说，“基于讨论的文档”对新用户来说通常很费力，因为它通常涉及阅读一篇帖子，然后是一系列更新或修改原始帖子的讨论。当然，我只是代表我自己发言，我也明白其他人可能不这么认为 
1 个赞
是的，我也不喜欢那样。 而且冗长的回复尾巴本身就可能让人望而却步。这里的想法（虽然我明白通常会有延迟）是将所有相关信息移到原始帖中，以免出现这种情况。我们也尽量将不同的讨论分成单独的主题（在可能的情况下进行标记），以便更容易搜索。我们还设置了一些自动删除计时器，在一定时间后清除旧回复。这还在进行中，但希望我们正朝着正确的方向前进。
2 个赞
是的。我认为在某种程度上你无法避免混淆，但很高兴知道你正在努力（尽管我怀疑你会走得那么远，删除已被纳入随后编辑的OP的评论，这通常是主要的浪费时间的事情）。
但我最初的观点并非如此。我想我太晚意识到你当然不是一个F/LOSS项目，所以可能不欣赏像我这样的路人试图提供“帮助”。
1 个赞
我们感谢社区创建的文档和建议。
自动删除计时器相当不加区分，所以它可能是一把双刃剑。 但目的是将更改文档的建议分离到一个单独的主题中，以便在必要/有用时保留历史记录。这是一个，嗯，“有机”过程，所以你可能会发现一些/许多未发生这种情况的例子。
不过，如果你发现有什么应该更改/改进的地方，我们还是相当积极的。
1 个赞
我指的不是那个，你看了我提供的链接吗？
我并没有让你去看文档类别，/docs 是由discourse docs插件生成的。
界面有很大的不同，更像是一个典型的知识管理系统，具有集中的搜索和筛选功能。它省略了回复，回复会像你从编辑历史中看到的那样，定期汇总到原始帖子中。
谢谢，但我不太确定这与我以为自己开始的对话有什么关系，所以我恐怕把它忽略了。不过，很高兴知道有这样的插件存在，我不是这个意思
根据您关于文档格式不合适或无法发现的评论，我在此处元（meta）上分享了一个指向该工具的链接，该工具以不同的格式呈现文档，并包含有助于发现的特性。
我理解您来自邮递员的背景，这里采取的不同方法可能不那么容易让您熟悉。作为在元（Meta）上提供帮助近九年的人，我可以向您保证，将文档更近距离地放在支持讨论旁边是非常有用的。
1 个赞
我明白了，抱歉我误会了。
我完全赞成你做你想做的事。我只是好奇你是否会赞成我向仓库提交一个 PR 来添加补充安装说明。我看到答案是你不会。
那么我在此退出，感谢你的宽容
1 个赞
我喜欢那个#documentation类别，并且经常使用它。我很困惑，因为我没有看到它不理想的明显原因。 
那里有很多有用的信息，在那里提交贡献将受到赞赏，并可能对他人有所帮助。