那么，我不是指包含数据库等的实例部署。
是否存在一种使用声明式格式（例如类别、标签、策略等）来维护实例的模式？我在想，如果我们的技术用户能通过 PR 提交更改建议，而不是通过主题帖和手动处理，那会很方便。但我没发现有任何插件或类似的“代码即配置”(as code)工具专注于 Discourse 的组织配置。
4 个赞
我认为期望是站点将使用预先提供的 Site feedback 类别来实现这一点。其描述是：“关于本站、其组织、运作方式以及我们如何改进它的讨论。”
这是一个有趣的想法。与让用户在常规主题中建议更改相比，它有什么好处？目标是有一种方法来跟踪随时间推移对站点配置所做的更改吗？
站点设置、类别、标签、策略等都可以通过 Discourse API 进行配置。有可能有一个脚本通过 API 在 git 仓库中管理站点的配置。当仓库中的 PR 被接受时，可以运行该脚本。从我的角度来看，这比通过 UI 手动更改站点配置要困难。
2 个赞
关于分类的“10-4”（收到）。目前我正在对现有模式进行一些众包。对我来说，关键是获得 GitOps 风格的社区参与，所以选择了这个，但如果它有帮助，我可以将其移交给另一个。
是的，我们对许多事情都使用一些代码即配置（config as code），这样您就可以获得清晰的版本控制、确定性的回滚、清晰的变更审查等。GUI（图形用户界面）更改并非不好（这也是我们今天通过社区反馈循环所做的），但它是一项手动操作，并且决策背景可能会随着时间的推移而丢失。而且组织结构存在于基础设施和实际对话之间，所以它不是部署或重新水合（rehydration）的事情。
是的，基于 PR（拉取请求）的触发器（甚至是一个 Issue）可以启动一个运行手册（runbook），该手册可以确定拟议的更改并执行操作。进行差异分析和代码检查（linting）可能很困难，这就是我一直在探索是否有人尝试过它的原因。这个要求绝对属于“锦上添花”的范畴，可能只会引起特定人群的共鸣。
2 个赞
我（而且我相当确定我们的编程语言社区）会非常喜欢这个功能。特别是，我希望能够在一个 GitHub 存储库上管理主题、组件和网站文本，这样大家就可以轻松提交拉取请求。常规网站设置也很不错，但最让人头疼的是在 Web UI 中维护这三项内容。如果今天不可能实现——而且我认为并非如此，至少对于付费/托管实例来说不是——能否将其重新归类为功能请求？
1 个赞
写完之后，我立刻想去检查一下用户界面。看起来这是可能的——至少可以从一个 git 仓库创建/导入一个主题！更新是如何工作的？它能拉取新的提交吗？我找到了 https://meta.discourse.org/t/installing-a-theme-from-a-private-git-repository/82584，但它没有讨论更新。
是否可以将现有主题或组件转换为跟踪一个 git 仓库？
您可以导出主题，将其上传到存储库，然后进行安装。
所有远程主题的顶部都有一个部分，您可以在其中决定在 Discourse 更新时是否要自动更新它。此外，还有一个后台作业会检查是否有可用更新的版本，您也可以手动检查新更新。当有可用新版本时，按钮会提供更新组件的选项。
您也可以在关于 Installing a theme or theme component 的指南中找到该信息。
如果您还没有找到，还有一个关于主题开发的教程。
3 个赞
太好了，谢谢你@Moin！这涵盖了我们网站定制的两个主要来源。
我仍然非常希望使用git来管理网站文本，因为其中许多（如指南和常见问题解答等）篇幅较长，内容非同小可，并且可以开源以供社区输入和审查。
其他的网站设置也最好能实现，但肯定没有那么关键。
这些通常基于staff类别中的一个主题。我认为你可以将它们移动到不同的类别并将帖子设为wiki。然后你的成员可以编辑它们。
你还可以使用 FAQ URL、Privacy policy URL 和 ToS URL 站点设置，并将它们托管在其他地方。
1 个赞
是的，但 FAQ URL 设置不幸的是具有其他行为，这使得它的使用非常适得其反。
我开始捣鼓一个 GitHub action，它通过 API 向 admin panel 的 site_texts 部分提交更新。目前它还很粗糙（并且因为某种原因，对于大值会返回 422 错误），但很有潜力。
肯定还需要更多工作。
1 个赞