就我个人经验而言，我的想法是：如果你已经足够了解 Ruby 和 Rails，能够轻松地为 Discourse 编写插件（或修改任何 Rails 类），那么通过插件来实现你在“分支”中所做的事情会容易得多。
如果我们还不足以轻松理解 Rails 和 Ruby 并编写 Discourse 插件，那么我的经验是：直接 Fork 并修改核心代码是“误入歧途”的。
我想打个比方（抱歉这个想法很简单）：
“有人觉得走路很困难，于是决定直接去跑步。”
如果不介意的话，让我解释一下：
在我开始编写 Rails 应用（与 Discourse 无关）并尝试编写 Discourse 插件之前，我有点迷茫，甚至对 Discourse 有些恼火。这就像第一次打高尔夫球：球不会直线飞行，需要大量练习才能将球打到球道中央。Fork 并修改 Discourse 核心，就像在你还不会用短铁杆切球和推杆之前，就直接在练习场拿出大号开球木杆！
我曾暂时停止对 Discourse 的“黑客式”修改（那是几个月前的事了），转而实际从零开始构建了一些 Rails 应用。之后（也只有在那之后），我才开始对 Rails 建立起某种“直觉性”的理解。从那以后，当我决定修改 Discourse 时（目前我已在生产环境中运行了自己编写的 6 个自定义插件），一切都变得直观起来，那些需要修改 Ruby 核心的插件也变得过于简单。
Ruby 非常灵活。我们可以覆盖任何类、任何对象，甚至可以重新定义 Ruby 的每一个方面。随着经验的积累，我们会开始感叹：“哇！我完全没想到 Ruby 如此灵活（而且强大）！”然后开始“变得危险”，因为我们能像超人一样在 Ruby 和 Rails 中自由翱翔。那时，我们才刚刚踏上 Ruby 和 Rails 的旅程，远未到终点！
凭借我在 2020 年积累的 Ruby 和 Rails 知识，如果现在让我重来，我绝不会像你所提议的那样去 Fork Discourse 并修改 Ruby 和 Rails 核心。因为一旦我们理解了 Ruby 类的基础以及元编程的基本概念，通过插件来覆盖和修改 Ruby 类简直太容易了。
我想表达的意思是（抱歉如此直接）：如果有人认为必须通过修改 Discourse 核心来实现一些微小的 Ruby 改动，那说明他们对 Ruby 和 Rails 的理解还不够深入；因为如果他们真的理解了，就不会去修改核心，而是会直接编写一个简单的插件来覆盖类，并享受“猴子补丁”（monkey-patching）的乐趣。
另一方面，如果我想做一些疯狂的事情，比如用 React 和 Ant Design 替换 Discourse 的 EmberJS，让自己陷入痛苦，那么 Fork 确实是唯一可行的途径！然而，在我看来，“Discourse”并非由“JavaScript 库”定义。Discourse 是由核心开发团队（这些人）的技能、他们对细节的关注、客户服务、开源代码开发的团队协作方式、他们的 SPA 功能管线以及他们所有的辛勤工作所定义的！仅仅因为可能更喜欢 Ant Design（配合 React）或 VueJS 而不是 Ember，就抛弃所有这些智慧，在我看来有点疯狂。
如果我们只是打算对 Discourse 核心进行零星的修改，这一点更是如此！为了这种目的去 Fork 它，抛弃那些真正的“人”（他们才是“真正的”Discourse，而非代码），未免有点“疯了”。
以上只是我 2020 年学习 Ruby 和 Rails 的个人经历。现在，基础部分已经变得容易，我也开始“变得危险”了，哈哈。我可以“随意进行猴子补丁”，但这并不总是好事；而这正是 Discourse 插件存在的意义。
保持核心坚如磐石，尽情通过插件在 Discourse 上“折腾”吧。
希望这能帮到你。
顺便一提，在写这条回复时，你写道：
这某种程度上证明了我的观点，你不觉得吗？
在 Discourse 中编写“插件”，从某个层面来说就是编写"Ruby 代码”；而对其他人来说，这还涉及更深层的内容（比如 EmberJS）。
在你开始编写 Discourse 插件之前，我的友好建议（虽然对你来说可能显得毫无价值）是：先开发一些 Ruby on Rails 应用。至少掌握 Ruby 和 Rails 的基础知识，之后，你自然会回答自己上面提出的问题。
今天早上，我和客户开了三个小时的电话会议，讨论一个 Rails 应用、验证、模型等内容。会议结束后，我稍作休息，编写了一些会议中确定的待办事项，然后读到了你的帖子。
在我看来，编写 Discourse 插件的最短路径，就是先学习 Rails。
希望这能帮到你！