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カテゴリについては、Discourse Metaフォーラムのモデレーションに関する問題を議論する場として使用しない方が、会話はより生産的になると思います。#site-feedbackカテゴリの方が、そのような議論にはより適しています。それは微妙な問題です。私自身も過去にそれを超えてしまったことがあります。
これは私の責任範囲外です。
編集：これは「ユーザー作成グループ」の良い使用例のようです。ユーザーがグループを作成し、他のユーザーが自由にそこに参加できるようにする。そのアイデアは数回提起されています。
PMを作成する必要はありません。元のトピックの焦点を絞った分岐である個別のトピックを作成するだけです。
しかし、私の公開トピックは議論なしにプライベートメッセージに変換され、閉じられます。例は複数あります。
ここにこのカテゴリがあるのは良いことです。そこにトピックを開始しようと考えていました。
フラグシステムに関するこのトピックについては、当初は特定のフォーラムについてではなく、一般的なことについて話していました。
Metaは1日あたり約150件の投稿があり、かなりのトラフィックがあります。その量のすべてをフィルタリングするのは誰にとっても困難です。ここでの私の全体的な印象は、これがタクシーの修理工場のようなもので、タクシーサービスをどのように運営するかについての話の場であるということです。他のフォーラムページのようなタクシーの助手席とは全く異なります。
議論に実質的に貢献できるトピックを作成することが重要だと思います。それは、あまりにも多くの範囲をカバーしようとするトピックではなく。
例えば、このトピックはOPで導入されたいくつかの異なる要素の混合であり、誰もが完全に貢献できるとは思えません。これは#communityトピックですが、フラグ付けのための新しい#featureのアイデアを浮かべているようです。引用されたテキストは、合意/不同意のフラグスコアに関するものですが、それは上記（そして、少し横道にそれると、すでに存在します。最近、フラグUIで軽視されていましたが、誰も使用していないと思ったからです。おそらく、良い#ux #review-queueトピックです:+1:）。また、サイトでのモデレーションの決定を批判しています。そして、返信が同じ投稿内でそれぞれ少しずつ絡み合っているため、意味のある方法で分割したり、トピックに戻したりすることも不可能です。
トピックを作成する際には、それが何についてのものであるかを決定することが重要だと思います。なぜなら、トピックは、分裂的で最終的に非生産的な会話につながることなく、すべてのものについて同時に議論することはできないからです。
明らかに、すべてのサイトは異なり、異なるアプローチを持っている可能性があり、そうする自由があるはずです。
私たちはここでメタでチームとして決定を下す傾向があります。
#featureリクエスト自体については、管理者やモッドが正しい選択をすると信頼する必要があると思います。彼らは何が期待されているか、何が期待されていないかについて良い感覚を持っており、しばしばチームとしてそれを達成するために協力します。ダッシュボードには、チームのサイズに応じて使用できる優れたレポートもあります（または、データエクスプローラーがあれば、それらが適さない場合はカスタムレポートを作成できます）。
それで、このトピックをどうすればよいでしょうか？それが何についてのものであるかを正確に反映するように、カテゴリを変更し、タイトルを変更しますか？そのためには明白な選択肢はないようです。それを2つ（またはそれ以上）のトピックにするための良い分割点もないようです。あるいは、それを閉じて、モデレーターの裁量でこれらの状況を処理するためにトピックを閉じる必要がある場合があるという事実を線引きして、機能は#featureトピックに、UXは#uxトピックに作成することを奨励しますか？
おそらく、カテゴリを変更した方が良いでしょう。UX のように、チームがコアの一部にできる Theme component として作成できる可能性があります。これは、pm bubbles が行ったことと同様です。
アイデアに関連しない投稿を選択するというアイデアはどうでしょうか。広範なトピックの管理方法に関するアイデアについて、別の Community トピックに入れることができます。
つまり、親のディスカッションとして作成し、アイデアのポイントを子トピックにすることができます。しかし、それは出発点に過ぎないでしょう。
信頼と管理について。例えば、コミュニティの安全地帯でのスピード違反やスピード違反自体で、信頼がどのように機能するかはわかっています。私たちは、安全でない運転をスピードに関連して排除できるように、制御機能を備えた車を作成できる技術レベルにいます。
編集:
それはフラグ付けのスコアとどう関係があるのでしょうか？メンバーの投稿にフラグを立てるモデレーターは、役立つフラグのためにフラグ付けを強化します。確かに、モデレーターチームを賢く選択すると言うのは素晴らしいことです。一部のシナリオでは、モデレーターレベルの担当者を決定するのは会社の責任者です。そのため、人間の条件に依存しない整合性を確保するための簡単なオプションが好まれる可能性があります。「誘惑に陥らないように」
1つの課題は、モデレーションと、歴史的記録のための編集/インデックス作成との間に違いがあることです。
多くの川は、海に向かう途中で蛇行しています。
もしこれがトピックの爆発に関連している場合、ここに移動しましょう
このトピック スレッドの新しいタイトルをお勧めします。フラグの整合性システムがないという主張を支持しない限り。それは私が同意しない大胆な主張です。
フラグ システムには制限がありますが、整合性がないと宣言するのは愚かです。もしそうなら、ここはそれを報告する場所ではありません。
誠実性システム、正直なところ、これについての私の意見はまだ真実です。
私は、モデレーターが単に彼らの意見に同意しない人々の投稿をフラグ付けしていたため、フラグ付けのスコアを上げていたモデレーターがいました。（モデレーターの乱用の非常に明確な例）。
フラグが検証されない（同意されない）場合、フラガーのスコアの％は低下します。
この指標は、フラガーがフラグ付けシステムを乱用している可能性があるかどうかをモデレーターチームに把握させるために、一部設けられていると信じています。
しかし、より適切に適合するようにタイトルを変更します。
このトピックはメタモデレーションを連想させます。そしてそれはジョージ・サンタヤナの言葉を連想させます。
「過去を思い出せない者は、それを繰り返す運命にある。」
以下のことを調べることをお勧めします。
それらのいくつかは失敗したと言えるでしょうし、いくつかは貴重な教訓を提供しています。また、いくつかは非常に長年にわたって非常にうまく機能し続けています。
私が知らない他の経緯もあるだろうと想像します。Digg、おそらく。Lobsters？ Delicious？ そしてもちろん、Fediverseがあり、Mastodonインスタンス、Diasporaインスタンスなどがあります。Google+、特にコミュニティ機能からの教訓もあるかもしれません。
しかし、上記のすべては規模を拡大し、自己統治することを意図したサイトであることに注意してください。Discourseサイトは、より限定的であり、管理され、キュレーションされていると思います。