您希望完成什么工作？
.md 文件您需要在何时完成？
您的预算（以美元计）是多少？
Discourse 在这方面缺失了什么？Discourse 能否得到改进以满足您的需求，从而让您完全无需使用 GitHub？
您提到了拉取请求（pull requests），所以需求可能是能够请求更改，然后在更改最终确定之前由他人进行审查和批准？我想您可以通过“Discourse 方式”来实现这一点，例如回复帖子以请求审查，或者在做出更改后将其分配给某人。我曾通过设置主题定时器自动删除回复取得了一些成功，这样主题就不会被大量琐碎的回复所拖累。
另一个想法是使用策略插件（policy plugin）。当某个主题被更改时，可以通知某个群组，并要求他们确认已阅读并同意该更改。
话虽如此，我认为这是一个非常棒的想法，我希望看到它被实现。我甚至觉得这对 Meta 板块也很有用！我们这里有很多关于 GitHub 仓库的主题，如果能直接在首帖（OP）中看到这些仓库的 readme.md 文件的更新，而无需在两个地方维护它们，那将非常理想。
对于 Discourse for Teams 来说，这也将是一个有用的功能，这样重度使用 GitHub 的团队仍然可以将 Teams 作为参考的“单一事实来源”，而无需每个人都频繁登录 GitHub。我想这可以成为代码审查插件的一部分，或者作为其配套插件。
这里最关键的是分支功能。其核心动机在于存在一种机制，可以对内容进行分支、改进、审查，然后合并。同样，它也允许审查者经历类似的过程，对分支本身进行更细微的修改，从而提供更精细的变更控制。
虽然我很希望如此，但缺失的部分并非微不足道：
对于那些不像我这样在意分支功能的人来说，这真是一个巧妙的办法。
感觉这在很多方面都能带来巨大的帮助。每当我找到合适的人选来负责这个项目时，我都希望能合作一番。也许这个工具最终能成为一款“官方”插件！（只能寄希望于此）。
如果核心用例是 .md 文件和通用语言，我仍然认为 Discourse 具有巨大优势，因为它具有对话性，并支持人们用通俗语言进行实际交流。正如你所说，关于知识的讨论通常希望在 Discourse 上进行。因此，我认为值得探讨如何将大部分内容保留在那里，否则会将注意力和焦点从你希望作为主要平台的内容上引开。
我可以想象这样的设置：
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.