これらを合わせると、意図せずミスを犯しやすいということです。
カテゴリのタグ要件が、モデレーターや管理者にも適用されるようにしてください。[3]
これはどのように設定されているかについては、Navigating Fedora Discussion — Tags, Categories, and Concepts - Fedora Discussion を参照してください。また、Ask Fedora をサイトに統合する予定であり、これはさらに重要になります。 ↩︎
サイト権限に対するsudoのようなアプローチの提案はあまり熱意を得られませんでしたが、これは最も大きな問題の1つをカバーします！ ↩︎
あるいは、このテスト の意味を反転させてください！
test("staff bypass tag validation rule", async function (assert) {
await visit("/");
await click("#create-topic");
await fillIn("#reply-title", "this is my new topic title");
await fillIn(".d-editor-input", "this is the *content* of a post");
Category.findById(2).set("minimum_required_tags", 1);
const categoryChooser = selectKit(".category-chooser");
await categoryChooser.expand();
await categoryChooser.selectRowByValue(2);
await click("#reply-control button.create");
assert.notStrictEqual(currentURL(), "/");
});
これには本当に同意します。これらのルールを設定した場合、おそらくそれらを本当に望んでいるのでしょう。私が使っているサイトで、私しか使っていないのに、自分で設定したルールに従うことをディスコースが保証してくれず、さらに「todo」を選択して新しい「to」タグを作成しないようにするために余分なタイピングが必要になるのは非常に迷惑です。
管理者にルールに従うことを強制してもらえれば満足ですが、それが無理なら、「ルールに従いたくないのですか？」という確認モーダルがあると良いでしょう。
あるいは、「スタッフがタグルールに従う」というサイト設定もあるかもしれません。これはかなり簡単そうです。
モデレーター向け: +1
管理者向け: -1
管理者はすべてをオーバーライドできる必要があります。管理者は、何ができるか何ができないかを知っているという基本的な前提があります。
これは、管理者/モデレーターの権限を使いにくくすることなく、良い中間地点になると思います…何が起こっているかを概説する何らかの警告…例えば：
#tag は #category に制限されています。スタッフ権限を使用してこれを #different-category に投稿してもよろしいですか？
これで問題ないです。自分のアカウントをモデレーターアカウントにし、セカンダリアカウントを管理者アカウントにします。
これは良いと思いますが、"Regular mode" for admins and moderators (e.g. something like "sudo") の方がさらに良い場所に追加されるでしょう。
はい、この機能は、タグ全体にわたる分散型ガバナンスを持つ大規模コミュニティにとって有用であるという私の+1を追加します。
いくつかの追加をここに示します。最後のスレッドに：
これはFedoraコミュニティにとって課題です。なぜなら、リーダーシップとコミュニティの両方がタグ管理のためのオープンポリシーに従っているからです。Fedoraの登録済みグループは、新しいタグをリクエストし、タグディスカッションモデレーターを割り当てることができます。Fedoraのリーダーシップはコミュニティと協力して新しいタグを作成し、コミュニティ全体（例：ドキュメント、Wiki、ウェブサイト、口コミ）でそれらを普及させています。さらに、幅広いトピックをカバーする大規模なコミュニティであるため、タグもたくさんあります！Fedora Discourseのすべてのタグを常に把握しているわけではありません。
そのため、サイト管理者（Fedora Discourse全体に様々な程度で積極的に参加している）が投稿にタグを追加したり、特定のルールを持つタグに参加したりすると、Fedora Discourse管理者がFedoraのオープンポリシーを破ってしまうという簡単な間違いが発生します。オープンポリシーは、グローバルサイトのガバナンスをコミュニティにとってより包括的でアクセスしやすくする方法です。このように、サイト管理者権限は、FedoraリーダーシップがコミュニティのためにFedora Discourseを実行する方法に対するオープンアプローチを妨害する可能性があります。
これは技術的には機能しますが、複数のタグに積極的に投稿するサイト管理者にとっては面倒な作業です。これはネガティブなユーザーエクスペリエンスです。なぜなら、時々（例えば、会議の合間の短い休憩でフォローアップアクションが必要な場合など）すぐに時間が取れないことがあるからです。最初にやろうとしていたこと（つまり、存在すると思われる関連タグで新しいスレッドを作成すること）をする前に、追加のユーザーフローに我慢することは困難です。
この機能リクエストは、管理者のオーバーライド能力を奪うものとは考えていません。むしろ、アクティブなサイト投稿者に対して、サイトルールやタグ付けの規範を破っていることを、実行中（事後ではなく）にサイト管理者に通知し、情報に基づいた同意を与えるものです。
私も今日、これに遭遇しました。うーん！そして昨日、善意で親切なTL4ユーザーがスレッドを分割したのですが、分割されたタグがタグ付けされませんでした。
お願いです、何か対策を講じてもらえませんか？これは管理者、モデレーター、あるいはTL4ユーザーにとっても、さらに困難になります。
Theme component の「管理者警告」のように、トピックのクローズではなく、タグ作成のためのものです。
大規模な執筆サイトで、Discourseへの移行作業を行っており、タグ、制限、その他のタグルールを熱心に活用する予定です。スタッフアカウントが誤って要件を回避できないようにするオプションは、実際に設定に労力を費やしているサイトにとって有益です。
ぜひ実現してください。必須です。また、管理者が特定のグループやタグのみを使用するように設定した場合、その管理者にも適用してください。ランダムなユーザーを装わなければ、設定の結果を確認できないのは、少し間抜けです。
個人的には、タグやカテゴリーを厳密に守る必要性を感じたことはありませんが、このトピック全体を読むと、一部のコミュニティにとっては非常に重要なことのようで、ユースケースは間違いなく理解できます。
これはすべてのコミュニティで必要なわけではありませんが、あると便利な機能なので、何らかのサイト設定が必要かもしれません。たとえば、
スタッフにタグの制限を適用する
または、すべての場所で制限を適用したくない場合に備えて、設定をより細かくすることもできます。カテゴリ設定では、カテゴリで適用するタググループを設定し、ドロップダウンメニューのサイト設定で適用するカテゴリを選択しますか？
スタッフの特定のカテゴリにタグを適用する
カテゴリを選択