DBなどを含むインスタンスのデプロイメントの話ではなく、
宣言的なフォーマット（カテゴリ、タグ、ポリシーなど）を使ってインスタンスを維持するパターンはありますか？ 技術系のユーザーが、トピックのスレッドや手動での対応ではなく、PR経由で変更を提案できると良いなと考えていました。しかし、Discourseの組織的な設定に焦点を当てたプラグインや、その他の「as code」ツールはまだ見当たらないようです。
「いいね！」 4
サイトは、事前にシードされた Site feedback カテゴリをこれに使用することが期待されていると思います。その説明は次のとおりです。「このサイト、その構成、機能、および改善方法に関するディスカッション。」
それは興味深いアイデアですね。通常のトピックでユーザーが変更を提案するよりも、どのような利点があるのでしょうか？ サイトの構成に加えられた変更を時間の経過とともに追跡する方法を持つことが目標ですか？
サイトの設定、カテゴリ、タグ、ポリシーなどは、Discourse API で構成できます。API を介して git リポジトリでサイトの構成を管理するスクリプトを作成できる可能性があります。スクリプトは、リポジトリで PR が承認されたときに実行できます。私の見解では、UI を介してサイトの構成を手動で変更するよりも困難になります。
「いいね！」 2
カテゴリについては10-4です。今のところ、既存のパターンでクラウドソーシングをしていました。私にとっては、そのGitOpsスタイルのコミュニティエンゲージメントを得ることが重要なので、これに落ち着きましたが、もし役に立つなら他のものに移行することもできます。
そして、はい、私たちは多くのことに対してコードとしての設定を少し使用しているので、クリーンなリビジョン管理、決定論的なロールバック、明確な変更レビューなどを得ることができます。GUIベースの変更は悪くありません（そして、今日の私たちのコミュニティフィードバックループを通じて行っていることです）が、それは手動操作であり、意思決定の文脈は時間とともに失われる可能性があります。そして、インフラストラクチャと実際の対話の間には組織の構造が存在するため、デプロイメントや再水和のことではありません。
そしてはい、PRベースのトリガー（またはIssueでも）は、提案された変更を特定して操作を実行するランブックを開始できます。差分分析とリンティングを行うことは難しい場合があるため、誰かがすでに試したことがあるかどうかを調べていました。この要求は間違いなく「あったら嬉しい」の部類に入り、特定の層にしか響かない可能性があります。
「いいね！」 2
私（そして私たちのプログラミング言語コミュニティも確信していますが）はこの機能を絶対に気に入るでしょう。特に、テーマ、コンポーネント、サイトのテキストを、人々が簡単にプルリクエストを送信できるGitHubリポジトリで管理できるようにしたいです。一般的なサイト設定も望ましいですが、最も維持が困難なのはWeb UIでのこれらの3つの項目です。
これが今日可能でない場合（有料/ホストインスタンスでは少なくともそうではないと思います）、機能リクエストとして再分類することは可能でしょうか？
「いいね！」 1
それを書いた直後に、UIを再確認しようと思いました。どうやらそれは可能のようです — 少なくともgitリポジトリからテーマを作成/インポートすることは！アップデートはどうなりますか？新しいコミットをプルすることはできますか？https://meta.discourse.org/t/installing-a-theme-from-a-private-git-repository/82584を見つけましたが、アップデートについては議論されていません。
既存のテーマやコンポーネントをgitリポジトリを追跡するように変換することは可能ですか？
テーマをエクスポートしてリポジトリにアップロードし、インストールすることができます。
すべてのリモートテーマの上部には、Discourseが更新されたときに自動的に更新するかどうかを決定できるセクションがあります。さらに、Discourseが更新されたときに、より新しいバージョンが利用可能かどうかを確認するバックグラウンドジョブがあり、手動で新しい更新を確認することもできます。新しいバージョンが利用可能な場合、ボタンはコンポーネントを更新するように促します。
この情報は、Installing a theme or theme component のテーマのインストールに関するガイドでも確認できます。
まだ見つけていない場合は、テーマ開発に関するチュートリアルもあります。
「いいね！」 3
素晴らしい、ありがとうございます @Moin！これで、サイトのカスタマイズの大きな2つのソースがカバーされました。
サイトテキストを管理するためにgitを使用したいと思っています。なぜなら、それらの多く（ガイドラインやFAQなど）は長くて複雑であり、コミュニティの意見やレビューのためにオープンソースにできるからです。
他のサイト設定もあれば嬉しいですが、それほど重要ではありません。
これらは通常、スタッフカテゴリのトピックに基づいています。別のカテゴリに移動して、投稿をウィキにすることができると思います。そうすれば、メンバーが編集できるようになります。
また、FAQ URL、Privacy policy URL、ToS URL のサイト設定を使用して、これらを他の場所にホストすることもできます。
「いいね！」 1
しかし、FAQ URL 設定は、この目的には非常に自己破壊的な他の動作をしてしまいます。
ソース管理でコンテンツを管理できることが明確になったことを指摘しておきます。このトピックをご覧ください。GitHubで管理されています。
一番下にあります。
ただし、この機能がリリースまたは発表されたかどうか（または意図されているかどうか）はわかりません。
「いいね！」 1
API経由で管理パネルのsite_textsセクションに更新を送信するGitHubアクションをいじり始めました。現時点ではかなり初歩的で（大きな値でなぜか422エラーが発生して失敗しますが）、有望です。
間違いなく、もっと作業が必要です。
「いいね！」 1