アカウント名:
パスワード:
いっそ記名モデレーションにしよう(先祖返りみたいだけど)。 500人くらいのモデレーション委員会みたいなのをつくる。 で、誰がどんなモデレーションをしたかが一目瞭然になる。 登録ユーザーは、誰のモデレーションを信用するか、あるいは 信用しないかを調整して、言ってみれば重みつき多数決的に 個々のコメントのスコアを得る。
現状だと、Oliver氏はじめサイト側が考えている モデレーションの意味・意義が、必ずしもモデレータに伝わっている ようには思えない。サイト側が周知させようとしている モデレーションの意味に賛同するしないは置いといて
いっそ記名モデレーションにしよう(先祖返りみたいだけど)。 500人くらいのモデレーション委員会みたいなのをつくる。で、誰がどんなモデレーションをしたかが一目瞭然になる。登録ユーザーは、誰のモデレーションを信用するか、あるいは信用しないかを調整して、言ってみれば重みつき多数決的に個々のコメントのスコアを得る。
/.J内ではなくて外部に複数の"モデレーショングループ"が存在するようなモデルではどうでしょう？
そのような立場にどのような人が立候補すると想定しているのでしょうか？ /.Jで出てくる話題に関心があり、なおかつ一切コメントを書き込まない人たち？
> ミソは複数のグループが存在することで グループ化して「価値観のあわないモデレートグループは無視する」で済む問題なら、現行システムでもスコアを見ないようにすれば似たようなものです。
モデレーションが「他人のコメントを評価する」仕組みである以上、どんな方法を取ろうがその評価に対する論争が避けられるとは思えないのですが。
それで、少なくとも、先に挙げた「ACに対するモデレートポリシー」の例などは、目に見える効果を持つと思います。なぜならこの問題は、「ACのスコアは低くてしかるべきだ」というポリシーと、「ACのスコアを特に低くする理由はない」というポリシーが明確に線引きできるからです。 このように線引きのしやすい問題については、モデレーショングループ制が十分に機能すると期待できます。
記名モデレーション制も悪くはないですが、何百人といるアカウント持ちの個々にフィルタ設定をするのは現実的ではないし、また個人の意見は統計的な信頼度で劣る（多かれ少なかれ偏っている）ので、グループ単位でポリシーを共有した方が現実的だと考えます。
このように線引きのしやすい問題については、モデレーショングループ制が十分に機能すると期待できます。すくなくともこの点に関していえば機械的な振り分けで済む問題なので、グループ制とは無関係に現行システムにオプションを追加するだけで実現可能ですよね？
このように線引きのしやすい問題については、モデレーショングループ制が十分に機能すると期待できます。
主観に左右されるモデレーションのポリシーを本当にグループ内で共有できるのか、かなり疑問に感じます。 ポリシーの一貫性を保ちたいなら、そのグループに参加できるのはある程度限られた「特権」モデレータにしなければ無理なんじゃないかと思うのですが。
M1権限が今のルールで与えられ任意のグループに参加できる形を取るとするなら、ポリシーに一貫性のないグループが濫造されて、運用側にはグループ管理のコストが増えながら得られる成果はあまり期待できないような気がします。
それにそういった closed なグループは馴れ合いの場と化して、今以上にひどい組織票的な個人攻撃モデレートなどの温床になりそうです。
あ、もしかして「外部」ってのはもともとそういう話だったんでしょうか？
…それでは、モデレートする際に、そのモデレーションがどのポリシーに従ったものか選択できるようにする…というアイディアではどうでしょうか。これでも本質的には同じ機能を提供できると思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
記名モデレーションにしよう (スコア:2, すばらしい洞察)
いっそ記名モデレーションにしよう(先祖返りみたいだけど)。 500人くらいのモデレーション委員会みたいなのをつくる。 で、誰がどんなモデレーションをしたかが一目瞭然になる。 登録ユーザーは、誰のモデレーションを信用するか、あるいは 信用しないかを調整して、言ってみれば重みつき多数決的に 個々のコメントのスコアを得る。
現状だと、Oliver氏はじめサイト側が考えている モデレーションの意味・意義が、必ずしもモデレータに伝わっている ようには思えない。サイト側が周知させようとしている モデレーションの意味に賛同するしないは置いといて
Re:記名モデレーションにしよう (スコア:1)
/.J内ではなくて外部に複数の"モデレーショングループ"が存在するようなモデルではどうでしょう？
まるで意味がない (スコア:1)
そのような立場にどのような人が立候補すると想定しているのでしょうか？
/.Jで出てくる話題に関心があり、なおかつ一切コメントを書き込まない人たち？
ある意味では現行の「自分がコメントしたストーリーにはモデレートできない」の拡大版ですが、個人的には立候補者はそんなに多くないと思うし、そのために今以上に偏った傾向が出てくる危険があります。
ま、実際にはそんなシステムにしたとしても、どうせACか別アカウントで書き込むだけでしょうね。
うじゃうじゃ
Re:まるで意味がない (スコア:1)
モデレーションが複数平行して存在すれば、理想的には、その数だけの多様な価値観からのモデレートができます。これによって、自分の価値観（興味と読み替えても良いです）に近いモデレーションを選び出すことで、自分にとって有益な（とモデレートされた）情報が拾いやすくなったり、あるいは、複数の異なる価値観からモデレートされた結果を比較することで、多元的にコメントを評価できるようになると思います。
ミソは複数のグループが存在することで、多次元的なモデレーションを実現できる（少なくてもシステム的には）点です。それぞれのモデレーショングループのモデレート結果は偏っていても良い（というか偏った方が面白い）です。
別にコメントを書き込んでもかまいませんが、今のＭ１も自分が書き込んだ記事にはモデレートできませんから、なにか違いがあるようには思えません。
たぶんこの疑問は「外部に」という言葉を使ったのが悪かったのだろうと思いますが、別に/.J内部に組み込めるなら外部に置く必要はありません。外部と書いたのは、/.Jと別個に構築すれSlashCodeをハックしなくてよいので楽かなあ、くらいの気持ちで書いただけです。
/.Jに機能として追加するなら、モデレートするか否か設定するときに、「どのモデレーションポリシーに従ってモデレートするか」を各人が選ぶようにすればよいと思います。
モデレート結果を見る側は、「どのモデレーションポリシーによるモデレートを表示するか」を選択できるようにします。ここで「すべてのモデレーションポリシーの平均」も表示できるようにすれば、現行モデレーションシステムと同じものを残すこともできます。
また、いくつかのモデレーションポリシーをACに解放するようにすれば、ACにもモデレート権を提供することができ、一方でACのモデレーションが信用できない人の為に、非ACのみからなるモデレーションを表示することもできるでしょう。
Re:まるで意味がない (スコア:1)
完全に誤解してしまいました。
> ミソは複数のグループが存在することで
どうなんでしょうかねえ？
結局はそのグループごとに「モデレーションはどうあるべきか」という論争が再現されるだけのような気がします。
無理にグループ化するよりは記名モデレーションとし、個々に誰と誰のモデレーションを採用するか選ぶような形の方が現実的ではないでしょうか。
当然モデレータに対する非難などは起こるでしょうが、それはグループに分けても攻撃の対象が個人であるかグループであるかの違いでしかありません。現状は全体で１グループになっているためにモデレート行為全体が論争の的になっているわけですが。
グループ化して「価値観のあわないモデレートグループは無視する」で済む問題なら、現行システムでもスコアを見ないようにすれば似たようなものです。
モデレータの集団が全体でもグループでも、自分の価値観と合わないモデレーションを非難する人は必ず出てくるでしょう。
モデレーションが「他人のコメントを評価する」仕組みである以上、どんな方法を取ろうがその評価に対する論争が避けられるとは思えないのですが。
うじゃうじゃ
Re:まるで意味がない (スコア:1)
たとえば別の枝で議論になっているACの問題にしても、「ACは基本的にすべて-1モデレートするポリシー」のモデレーショングループと、「ACかどうかをモデレーションに反映させることは原則禁止」のモデレーショングループが共存していれば、ユーザは一方を選ぶことで、ACの扱いとモデレーションシステムを享受し続けることができます。モデレーションが一つしか存在しない場合、/.Jが上記のどちらかのポリシーを選択したら、そのポリシーになじめないひとはスコア表示をOFFにする以外の選択肢がなくなってしまいます。
私もそう思います。私のアイディアで、個別のモデレートに関する論争がなくなると言いたいわけではありません。
でも、「唯一正しいあるべきモデレーション」を妄想する無意味な論争を減らす役には立つでしょう。
＃要は「多様性」なんです
Re:まるで意味がない (スコア:1)
>でも、「唯一正しいあるべきモデレーション」を妄想する無意味な論争を減らす役には立つでしょう。
グループ化したところで「唯一」ではなくなるだけで、そのグループ内での「あるべきモデレーション」についての論争が続くことには変わりないでしょう。
外部からの個々のグループに対する非難や論争も目に見えています。
現状比べれば多少の変化はあるでしょうが、改善されたと言えるような変化になると期待できる根拠はないと思うのですが。
うじゃうじゃ
Re:まるで意味がない (スコア:1)
私のアイディアは、議論・論争・批判・非難が消えないことを前提とした上で、では、どうすれば個々人が「自分にとって最善のモデレーションシステム」を得ることができるか…が出発点になっています。
それで、少なくとも、先に挙げた「ACに対するモデレートポリシー」の例などは、目に見える効果を持つと思います。なぜならこの問題は、「ACのスコアは低くてしかるべきだ」というポリシーと、「ACのスコアを特に低くする理由はない」というポリシーが明確に線引きできるからです。
このように線引きのしやすい問題については、モデレーショングループ制が十分に機能すると期待できます。
p.s.
記名モデレーション制も悪くはないですが、何百人といるアカウント持ちの個々にフィルタ設定をするのは現実的ではないし、また個人の意見は統計的な信頼度で劣る（多かれ少なかれ偏っている）ので、グループ単位でポリシーを共有した方が現実的だと考えます。
グループ制 (スコア:1)
主観に左右されるモデレーションのポリシーを本当にグループ内で共有できるのか、かなり疑問に感じます。
ポリシーの一貫性を保ちたいなら、そのグループに参加できるのはある程度限られた「特権」モデレータにしなければ無理なんじゃないかと思うのですが。
M1権限が今のルールで与えられ任意のグループに参加できる形を取るとするなら、ポリシーに一貫性のないグループが濫造されて、運用側にはグループ管理のコストが増えながら得られる成果はあまり期待できないような気がします。
グループに参加するにはそのグループ内のメンバーの同意が必要とする手もありますが、その場合は新規グループを作る権利に制限を設けないと少人数/個人グループが氾濫するでしょう。それにそういった closed なグループは馴れ合いの場と化して、今以上にひどい組織票的な個人攻撃モデレートなどの温床になりそうです。
そんなわけでグループ制は現行の「単一グループ制」と「記名モデレートwithフィルタリング」の悪い点ばかりを寄せ集めたものになってしまうんじゃないかと。
極めつけかつ無謀な方法としては、/.-Jの内容を取り出して、独自のルールでモデレート/フィルタリングするサイトを別に立ち上げて…そのシステムのコードを公開すればリソースと根性のある人が多様なモデレートグループを立ち上げてくれるかと。
あ、もしかして「外部」ってのはもともとそういう話だったんでしょうか？
うじゃうじゃ
Re:グループ制 (スコア:1)
明確にして議論して来なかったのですが、私はモデレータの人数は大幅に増やすことを前提として考えていました。いっそ、誰もがモデレーションできるようにするのがいいでしょう。
で、モデレータの数が増えれば、統計的なメカニズムが働いて、グループのポリシーに反する（あるいは微妙な）モデレーションは相対的に淘汰されると期待できます。その辺のメカニズムは現行モデレーションシステムと同じです。ポリシーの濫造というのは確かにありそうです。そこは、たとえば利用者が少ないポリシーは定期的に排除する等の工夫が必要でしょうね。なるほど、その可能性は高いですね。もともとグループは、システムの便宜から提案したものなので、導入しなくてもよいならしないほうが良さそうです。
…それでは、モデレートする際に、そのモデレーションがどのポリシーに従ったものか選択できるようにする…というアイディアではどうでしょうか。これでも本質的には同じ機能を提供できると思います。運用としては、そんなイメージです。実装としては…たとえばMozilla用のXULアプリとして実装し、/.Jを見ながらコンテキストメニューでモデレート…なんてUIにすれば、気楽に利用できるんじゃないかと考えていました。
Re:グループ制 (スコア:1)
ついでに係数も選べると面白いかもしれない。（おもしろおかしいは×２とか）
>たとえばMozilla用のXULアプリとして実装し、/.Jを見ながらコンテ キストメニューでモデレート
えーと、proxy&httpサーバとして/.Jの内容をキャッシュし、再構築したものをブラウザで表示/書き込み/モデレートするアプリとか。
でもやっぱり/.Jのモデレーションとは独立したモデレートサイトを立ち上げて、有志で勝手にモデレーションするようにすると、/.J本体の負荷も軽減できるしモデレーションポリシーごとにサイトを立ち上げることができて面白そうですね。
うじゃうじゃ