Is diversity of opinion of benefit to community health? からの議論の続きです。
フラグ付けの整合性を見たいです。スタッフとカテゴリモデレーターは、対象となっている、またはそのフラグの発信元であるフラグを管理することは許可されるべきではありません。
Discourseのセットアップには明確な欠陥があります。これは技術的な解決策が必要です。
NOTR: 偉大なトピックがその広範な範囲のために閉じられたことに非常に失望しました。単なる「サブトピックの爆発」の提案で。このトピックは、親トピックにリンクされた子トピックを開始して、継続して成熟させることができたはずです。私の意見では非常に非生産的です - 市民的な議論を奨励するためには、攻撃的な対立が存在しない場合、トピックの多様性は妨げられることなく流れる必要があります。ハードストップの代わりにフローをガイドします。
リンク先の他のトピックは読んでいません。
スタッフユーザーが一人しかいないすべてのインスタンスでは、それはどのように機能するのでしょうか？ 
サイトトグルを使用できるスタッフが1名のみの場合。または…
管理者は1名のみが2番目のモデレーターユーザーを作成できます。スタッフが1名のみというのは非常に特殊な状況です。
さらに、単一のスタッフメンバーは管理者であり、モデレーターレベルのユーザーを含む、ユーザーができないことを実行できます。
素晴らしい質問ですね。答えは「機能しない」だと思います。
コミュニティフォーラムで、モデレーターのスタッフとユーザーアカウントの間で見解の相違がある場合、モデレーターがフラグを立てられた場合、一般的にその種のフラグにうまく対応することはできません。警察官が自分のパトカーの駐車違反切符を通常発行しないのと同じです。
単一のスタッフサイトを使用する場合。スタッフメンバーは管理者です。管理者アカウントは究極の制御レベルを持ち、ほとんどのルールに影響されません。
つまり、カテゴリセキュリティに関係なく、管理者は作成/返信/表示できます。
モデレーターアカウントはカテゴリセキュリティルールに従います。モデレーターがプライベートカテゴリへのアクセスを許可されていない場合、それを見ることはできません。
管理アカウントとは別に、モデレーション専用のアカウントを作成することも良い考えです。直接的な管理業務とハイブリッド化するためです。
メンバーが、私が作成したトピックに返信できなかったため、DMを送ってきたことが何度かありました。
フラグの対象となることと、フラグの発信元であることは、別々のケースのように感じます。モデレーターが作成したフラグを管理できないようにすることは、モデレーターのワークフローに影響を与える可能性があります。例えば、モデレーターがスパムとして投稿をフラグ付けし、後でレビューキューからフラグを処理するために戻ってくるかもしれません。
モデレーターがフラグの対象となるケースは、難しい問題のように思えます。このようなケースでは、サイトのモデレーターがチームとして状況を検討する必要があると思います。リスクとしては、モデレーター同士を対立させるためにフラグが使用される可能性があることです。
そのトピックのOPにある質問は、私も興味のあるものです。これは私にとって不当な要求かもしれませんが、私は来週、数人のチームメンバーが待ち望んでいた休憩を取っている間、Metaのモデレーションを手伝っています。トピックを閉じた決定に疑問を呈する代わりに、トピックの応答で提起されたさまざまなサブの問題に対処するために、別々のトピックを作成するという提案を受け入れることはできませんか？
私が議論しようとしたことはほとんどすべてが却下され、制裁されました。
すべての参加者が真剣なトピックを意味のある方法で探求できるように、成熟し、経験豊富で、バランスの取れた、有用な意見の対衡をもってすべてが議論されてきました。これは、私が現在無償で関与している、ソフトウェア開発における「次世代のデジタルコミュニティのため」のデザインと倫理に情報を提供するものです。1) 医療倫理/慢性ケアと研究、2) 企業統治がISO規格の策定/改善につながるもの。
モデレーションのモデレーションを歓迎します。
プライベートな議論に人々を招待したいと考えています。返信なしのグループを依頼しました。
簡単な解決策は、モデレーター/管理者が単一の投稿を非表示にする機能を復元することです。ボットアカウントからのスパムの場合、削除とユーザーの停止/削除がうまく機能します。
スパム投稿は非表示にされ、別のモデレーターチームメンバーがレビューしてフラグを検証できます。
私の意見では、それは誘惑を残します。非常に優れた同期したモデレーターチームは機能できます…しかし、技術的な解決策オプションが利用可能であれば、それはコンプライアンスを保証します。
モデレーターには、多くの便利な機能があります。例：
必要に応じて、ユーザーに一時的な沈黙を与えます。たとえば3日から1週間。DMでユーザーに通知し、この問題については他のモデレーターを待つ必要があることを伝えます。
非常に真実です。チームは非常にdeservedな休憩を必要としています。そしておそらく、最近ここでモデレーションが時々オフ/ラッシュのように感じられる理由です。
この問題について考える別の方法は、モデレーションをより透明にする技術的な解決策を見つけることです。
Community Building カテゴリー全般について言えば、Discourse Metaフォーラムのモデレーションに関する議論の場としてこれを使うのではなく、対話がより生産的になると思います。そのような議論には Contribute > Site feedback カテゴリーの方が適切です。これは微妙な線引きですね。私も過去にこの線を越えたことがあります。
これは私の責任範囲外です。
編集: これは「ユーザー作成グループ」の良い例になると思います。ユーザーが他のユーザーが自由に参加できるグループを作成できるようにすればよいでしょう。このアイデアは以前にも何度か持ち上がっています。
PMを作成する必要はありません。元のトピックの焦点を絞った分岐である個別のトピックを作成するだけです。
しかし、私の公開トピックは議論なしにプライベートメッセージに変換され、閉じられます。例は複数あります。
ここにこのカテゴリがあるのは良いことです。そこにトピックを開始しようと考えていました。
フラグシステムに関するこのトピックについては、当初は特定のフォーラムについてではなく、一般的なことについて話していました。
Metaは1日あたり約150件の投稿があり、かなりのトラフィックがあります。その量のすべてをフィルタリングするのは誰にとっても困難です。ここでの私の全体的な印象は、これがタクシーの修理工場のようなもので、タクシーサービスをどのように運営するかについての話の場であるということです。他のフォーラムページのようなタクシーの助手席とは全く異なります。
議論に有意義に貢献できるトピックを作成することが重要だと考えます。あまり広範囲をカバーしようとするトピックは避けるべきです。
例えば、このトピックはOP（Original Post）で導入された複数の異なる要素が混在しており、誰かがそれぞれの要素に完全に貢献できる状態にはなっていません。これは#community-building（コミュニティ構築）のトピックですが、フラグ付けのための新しい#contribute:feature（機能）のアイデアを浮上させているように見えます。引用されたテキストは、合意/不同意のフラグスコアに関するものですが、これはそれ[1] に関連しているようには見えません。さらに、サイトのモデレーション決定を批判しています。そして、返信が同じ投稿の中でそれぞれの要素と絡み合っているため、意味のある方法で分離したり、再び話題に戻したりすることも不可能です。
トピックを作成する際には、何を主題としたいかを明確にすることが重要です。トピックは一度にすべてのことを扱うことはできず、そうすると会話は分断され、最終的に生産的ではなくなります。
もちろん、すべてのサイトが異なるため、これに対するアプローチも異なる可能性があり、それぞれが自由にアプローチを選ぶべきです。
ここでは、私たちもチームとして意思決定を行う傾向があります。 
Contribute > Feature（機能）リクエスト自体についてですが、管理者やモデレーターが正しい選択をするのを信頼する必要があります。彼らは、何が期待され、何が期待されないかをよく理解しており、チームとしてそれを達成するために多くの場合協力します。また、チームの規模に応じて、オーバーサイト（監視）として使用できるダッシュボード上の良いレポートもあります（適合しない場合は、データエクスプローラーがあれば独自のものを作成することもできます）。
では、このトピックをどうすべきでしょうか？適切に内容を反映させるために再分類・再タイトル化する？それには明確な選択肢が見当たりません。2つ（またはそれ以上）のトピックに分けるための良い分割点も見当たりません。それとも、これを閉鎖し、機能を#contribute:feature（機能）トピックに、UXを#contribute:ux（UX）トピックとして作成することを促し、モデレーター裁量でこれらの状況に対応するために時にはトピックを閉鎖する必要があるという事実で区切りをつけるべきでしょうか？
(そして、それはわずかにそれとは関係なく、すでに存在します。ただし、最近では誰も使用していないと考えていたため、フラグUIでやや軽視されていました。潜在的には良い#contribute:ux（UX）review-queue（レビューキュー）のトピックです ) ↩︎
カテゴリを再分類した方がいいかもしれませんね。もしかしたら、Contribute > UX を Customization > Theme component として扱えば、チームが必要だと感じれば最終的にコア機能の一部になるようなカスタマイズが可能になるはずです。これは、pm bubbles がコアに取り込まれた経緯に似ています。
アイデアに関連しない投稿を選ぶというアイデアも良いかもしれません。そうした投稿は、Community Building 内の「アイデア」トピックとは別に、幅広いトピックをどう管理するかについての議論用に配置するとよいでしょう。
例えば、親となるディスカッションを作成し、アイデアのポイントを子となる新しいトピックとして分けることも可能です。ただし、それはあくまで出発点に過ぎません。
信頼 versus 管理についてですが、例えばコミュニティの安全ゾーンや速度制限そのものにおいて、信頼がどれほど機能するか私たちはよく知っています。今の技術レベルでは、車の制御を制限することで、速度に関連する危険な運転を潜在的に排除することも可能です。
追記：
これはフラグスコアとどう関係するのでしょうか？モデレーターがメンバーの投稿にフラグを立てると、そのメンバーの「役に立つフラグ」のスコアが上昇します。確かに、「モデレーターチームを慎重に選べばよい」と言うのは簡単です。しかし、一部のケースでは、誰にモデレーター権限を与えるかは会社のトップが決定します。そのため、人間の特性に頼らず、整合性を確保するためのシンプルなオプションの方が好まれるかもしれません。「誘惑に負けないよう導くこと」こそが重要です。
1つの課題は、モデレーションと、歴史的記録のための編集/インデックス作成との間に違いがあることです。
多くの川は、海に向かう途中で蛇行しています。
もしこれがトピックの爆発に関連している場合、ここに移動しましょう
このトピック スレッドの新しいタイトルをお勧めします。フラグの整合性システムがないという主張を支持しない限り。それは私が同意しない大胆な主張です。
フラグ システムには制限がありますが、整合性がないと宣言するのは愚かです。もしそうなら、ここはそれを報告する場所ではありません。
誠実性システム、正直なところ、これについての私の意見はまだ真実です。
私は、モデレーターが単に彼らの意見に同意しない人々の投稿をフラグ付けしていたため、フラグ付けのスコアを上げていたモデレーターがいました。（モデレーターの乱用の非常に明確な例）。
フラグが検証されない（同意されない）場合、フラガーのスコアの％は低下します。
この指標は、フラガーがフラグ付けシステムを乱用している可能性があるかどうかをモデレーターチームに把握させるために、一部設けられていると信じています。
しかし、より適切に適合するようにタイトルを変更します。
このトピックはメタモデレーションを連想させます。そしてそれはジョージ・サンタヤナの言葉を連想させます。
「過去を思い出せない者は、それを繰り返す運命にある。」
以下のことを調べることをお勧めします。
それらのいくつかは失敗したと言えるでしょうし、いくつかは貴重な教訓を提供しています。また、いくつかは非常に長年にわたって非常にうまく機能し続けています。
私が知らない他の経緯もあるだろうと想像します。Digg、おそらく。Lobsters？ Delicious？ そしてもちろん、Fediverseがあり、Mastodonインスタンス、Diasporaインスタンスなどがあります。Google+、特にコミュニティ機能からの教訓もあるかもしれません。
しかし、上記のすべては規模を拡大し、自己統治することを意図したサイトであることに注意してください。Discourseサイトは、より限定的であり、管理され、キュレーションされていると思います。