すみません、古い投稿ですが、なぜテーマを GitHub のリポジトリとして設定しないのでしょうか？デザインチームと UX チームに GitHub 上のテーマ更新のアクセス権限を付与してください。
Discourse では現在、テーマを再構築時に自動的に更新する設定が可能です。
これにより、管理者はデザインチームや UX チームが行った変更を取り込むために再構築を行うだけで済み、後者には管理者権限は全く不要になります。
簡単な注意点です：
アクセス制御に関するコーディングでは、一般的にこれらの RBAC チェックはサーバー側で実行されるべきです。
クライアント側の JavaScript に記述された RBAC コードは、クライアントによって操作される可能性があります。
つまり、スタッフ、管理者、モデレーター向けの基本的な RBAC 権限を定義する際は、一般的に JavaScript ではなく Rails 側で行うべきです。
余談ですが、Discourse も現在「guardian」と呼ばれる機能を使用して RBAC を実装しています。これは class Guardian という Ruby クラスで、以下にあります：
もし開発者が Discourse API を呼び出して JavaScript コードに RBAC チェックを追加する予定がある場合は、ブラウザで実行されるコードは操作される可能性があるため、このコードが侵害されうることを念頭に置いてください。
私の推奨は、すべての基本的な RBAC コードがサーバー側で実行されるようにし、クライアント側の JavaScript でこれをショートカットしようとはしないことです。
Discourse 2.5 以降では、信頼レベル 4 とカテゴリモデレーターも存在します。
私も同様のケースがあります。私が運営している小規模な非営利コミュニティでは、ユーザーの一人がテーマとデザインを維持管理しています。
私と共同オーナー以外の誰にも、個人データ（メールアドレスなど）へのアクセス権を与えたくありませんが、モデレーターは4名います。
デザイナーが作業を進めるために、コンテンツがないコピーサイトを作成し、彼を管理者として設定し、その後、テーマやコンポーネントを手動でコピーしています。しかし、変更の検証にはコンテンツが必要になる場合があるため、この方法は望ましくありません。
ステージング/テストサイトにコンテンツを追加するのはどうでしょうか？それが一般的な推奨事項です。
開発者はステージングサイトでの開発を行い、テーマを GitHub にプッシュしましょう。ただし、アップグレードは引き続きご自身で行う必要があります。API を活用してアップグレードを実行し、開発者がそれをトリガーできるようにする方法を模索することも可能です。
それを支援できるツールを現在開発中です。
私たちも全く同じニーズを抱えています。どなたか解決策を見つけられた方はいらっしゃいますか？
この状況で役に立つかどうかわかりませんが、コンテンツが必要なだけであれば、populate rake タスクがあります。
ありがとうございます。残念ながら、現時点ではあまり役に立ちません。
デザイナーがあなたのデータを見るのを信頼しない場合、どのような解決策を想像しますか？
テーマをそこにプッシュするために discourse_cli を使用できるAPIキーを彼らに与え、その後、彼らが終わったら無効にするというのはどうでしょうか？
デザイナーが10万人のユーザーにアクセスできる理由など全くありません。また、GDPR規則にも違反します。テーマの更新のためだけにCLIキーを提供することは可能ですか？
申し訳ありません！ あなたがおっしゃる通りだと思います。
このトピックが作成された時（私の返信を書いた時の私の頭の中はそこにあったようです）とは異なり、現在では詳細なAPIキーが利用可能です。テーマ管理専用の新しいスコープを追加することは、それほど難しくないはずです。
Feature でテーマ開発者APIキーのスコープを求める新しいトピックを作成することも検討する価値があるでしょう。それは良いアイデアだと思います。
いいえ、そうではありません。そのサイトの規則に反する可能性はありますが、それらは変更可能であり、変更されるべきです。
@AV_C さんがこの tequirement の参照を投稿してくれると良いのですが。クライアントがユーザーベースやプライベートカテゴリへのアクセスを制限したいと思う理由は様々あることを強く理解できます。フル管理者であればメンバーのサインアップメールにアクセスでき、プライベートカテゴリにはクライアントのユースケースによっては他の機密情報が含まれる可能性があります。
@pfaffman さんの、制限された管理者APIを通じてこのようなギャップをカバーできるようにするというアイデアは良いと思います。デザイナーの作業が完了したら、必要になるまでキーを無効にすることができます。
これは、Jayさんの、ユーザーが「About」ページに管理者として表示されないようにするというアイデアにも合致するでしょう。