Wikipedia:井戸端/subj/拡張半保護の導入

井戸端のタグ：提案 | 保護 | 半保護 | 管理者 | 投票 | 告知 [編集]

拡張半保護の導入

先日井戸端で提案いたしました拡張半保護について。おおよそ意見は出尽くしたかと思われますので、導入のために投票を行いたいと思います。そのためまずはいくつか投票のための確認を行いたいと思います。

1.導入の目的

寝かしアカウントによる半保護突破編集への抑止策。

現状、半保護突破編集を阻止する手段が全保護しかなく、全保護されると無害な利用者の編集さえも禁止することになるため。

2.導入する機能

半保護と全保護の中間にあたる保護区分で、ある程度長期的に活動する利用者のみに編集を許可する。

3.承認条件

指定日数以上活動し、指定回数以上の編集を行ったユーザーのみが編集できる。能動的な承認/承認取り消しも可能にしておく。

（指定条件を満たすユーザーには自動的に「拡張承認された利用者」のフラグが付与され、指定条件を満たさないユーザーを敢えて承認する必要が生じればIPブロック適用除外のような感じでフラグを付与できます。）

おさらいとして、前回提案の内容を大雑把に説明するとこのようなものです。編集回数は投票で決定したいと思います。

この機能を導入するに伴い、拡張承認された利用者とその上位互換となる管理者の他に、ボット、インターフェース編集者にも拡張半保護されたページの編集権限を与えるようにする予定です。編集回数500回未満で拡張半保護されたページを編集する必要性が生じるユーザー群には事前に編集許可出すべきという考えです。削除者は編集回数500回前後で信任されたケースがないため、付けなくても問題はないと考えます。ここらへんは英語版あたりも参考にしております。

ただのしかばねさんから言及があった更に保護区分を増やす件に関しては、いったん拡張半保護を運用して更に区分が必要なときに改めて提案したほうが効果的ではないかと考えましたので、今回は盛り込みません。片っ端から選択肢を幾つも増やしても適切な使い分けに悩む管理者が出て来るでしょうし、ひとまず区分を一つ増やすだけでもある程度の効果は期待できるはずです。

また、念のため再度申し上げますが、運用ルールは投票進行とは別途で検討を行います。フラグの与奪基準など、ルールの話と導入自体に賛成/反対をここでいっぺんに行ってもグダグダになるだけです。今回の目的は「仕様を決めてシステム管理者に申請を行うこと」です。今回はこの「拡張半保護」が必要だと思ったら賛成、不要だと思ったら反対ということです。--Marine-Blue^{talk✿contribs❀mail} 2017年10月23日 (月) 15:15 (UTC)

投票前の確認

投票項目の簡単な確認です。念のため数日程度確認の時間を置き、特に問題がなければ投票ページの作成と告知を行い、予告期間後に投票を開始する予定です。

確認事項は次の通りです。まず日数は30日、60日、90日、120日あたりから択一で投票を行い、最も多かった選択肢を投票による決定事項にしたいと考えております。次に編集回数に関しては、大きな反対がなければ英語版を参考に500編集を採用したいと考えております。そしてフラグ付与に関しまして、私個人としましては管理者による付与が好ましいと考えております。IPブロック適用除外のような、編集という基本的な機能に対する巻き添えの制限を緩和する性質のものであるためです。

まとめますと、投票前の確認事項は以下の通りです。投票項目をいくつ設けるかの簡単な確認です。もし異論がなければ投票項目は導入への賛否を問い、賛成者に対して編集日数を四択で選んでもらうという形式になります。ある程度の運用事例を参考に提案しておりますので、選択肢を積極的に幾つも増やす必要はないのですが、意見が大きく分かれそうな部分は投票項目に加えたほうが良いと考えております。

それと最後に投票資格ですが、2017/8/17 0:00(UTC)以前にアカウントを作成したユーザーで、2017/10/23 0:00(UTC)時点で活動期間3ヶ月以上、編集回数500編集以上のログインユーザー（前回の提案以降にアカウントを作成したユーザーと投票提起時点で編集回数の少ないユーザーは投票不可）と致します。寝かしアカウントの抑止が目的であるため、本投票で寝かしアカウントの参加を許してしまっては意味が無いからです。--Marine-Blue^{talk✿contribs❀mail} 2017年10月23日 (月) 15:15 (UTC)

1. 日数の選択肢は30日、60日、90日、120日の四択でOK？
2. 反対がなければ編集回数は500編集。
3. 手動承認（フラグ与奪）は反対がなければ管理者で。
4. 拡張承認された利用者、管理者の他に、ボット、インターフェース編集者にも編集権限を与えるってことでOK？
5. 投票資格は2017/8/17 0:00(UTC)以前にアカウントを作成、2017/10/23 0:00(UTC)時点で編集回数500回以上。

コメント

投票資格の「2017/8/17 0:00(UTC)以前にアカウントを作成したユーザーで、2017/10/23 0:00(UTC)時点で活動期間3ヶ月以上」…申し訳ないのですが意味がよくわからないです。前者の日付は Wikipedia:井戸端/subj/保護機能の仕様変更について の日付、時刻は便宜上 00:00 UTC にしたものと思いますが、後者 2017/10/23 0:00 から遡って 3 か月前 = 2017/07/23 00:00 となるのではないでしょうか（寝ぼけたことを言っていたらすみません）。IP 利用者時代も含めるということですか?　「活動期間」というのもよくわからない言葉です。最初の投稿が 2017/07/23 00:00 に1回だけあって、 2017/10/22 23:00 から 23:59 までに 499回投稿があった場合は投票資格が得られるのでしょうか。それとも、この場合の活動期間は 2 か月　とみなされるのでしょうか。または、実際の活動期間としては 2 日という見方になるのでしょうか。--rxy（会話） 2017年10月23日 (月) 16:31 (UTC)

いくら2017/10/23 0:00(UTC)時点で活動期間3ヶ月以上で編集回数が500回以上あっても、前回の提案以降に作成されたアカウントだったら投票撹乱目的で作成された可能性があるから資格を与えないよ、ということではないでしょうか。ただし今回はその提案が直近3ヶ月以内にあったため、前者の条件は後者に完全に包含されていて死文になっています（これが、たとえば前回の提案が2017年4月とかであれば前者が意味を持ってきます）。--ひむちや (会話/投稿記録) 2017年10月24日 (火) 06:07 (UTC)

まとめの『5.投票資格は2017/8/17 0:00(UTC)以前にアカウントを作成、2017/10/23 0:00(UTC)時点で編集回数500回以上。』から判断するに、こういった提案をする際のテンプレートみたいなものを用意されており、死文の修正もれ、という感じじゃないですかね。主旨から言っても、例えば2017/07/30に登録し、2017/10/20時点で５００回以上編集されている方は、資格が有ると解釈できます。

(もし違うので有れば、速やかに訂正されるべきかと思います。)--ただのしかばね（会話） 2017年10月24日 (火) 14:09 (UTC)

皆様コメントありがとうございます。しばらく考えてみたところ、投票資格は捻り過ぎな気がしてきました。シンプルに「2017/8/17 0:00(UTC)時点で初回編集から3ヶ月500編集以上」でも十分に休眠アカウントの議論妨害を防ぐ目的は達成できるし、（相対的に見れば）無効票確認もしやすいでしょう。というわけで投票資格を「2017/8/17 0:00(UTC)時点で初回編集から3ヶ月、500編集以上」にしようかと思うのですが、よろしいでしょうか。--Marine-Blue^{talk✿contribs❀mail} 2017年10月24日 (火) 17:57 (UTC)

今回は案件が案件ですから、良いと思います。『アカウントの作成と初回編集だけしておき、こういった事態に備えた、寝かしアカウント』が仮に有ったとしても、その条件でしたら防げると思いますので。(そういったアカウントが有り、前回の提案を見て回数を重ねていたとしても、提案時点の状態で参加資格をという事にすれば、介入できない)--ただのしかばね（会話） 2017年10月24日 (火) 18:12 (UTC)

8/17時点での投稿回数を何らかの方法 (bot等) で調べられるならいいと思います。少なくとも人力では厳しい気が。私は8/17時点だと400編集くらいで多分条件を満たさないのですが、簡単な調べ方がわからないです。--ひむちや (会話/投稿記録) 2017年10月24日 (火) 23:16 (UTC)

RfA やら Wikipedia:井戸端/subj/半保護の期間を英語版同様の「登録から4日かつ10編集」に変更する提案 の時のように、いつも通り Bot で確認もします。…こういう規模の大きいことが想定される投票は mw:Extension:SecurePoll のほうが向いてはいるんですが、投票権がややこしくなると SQL から有権者名簿を作成して、その上 SecurePoll 自体の設定がとても面倒くさいんですよねぇ…　CU と同格のアクセスレベルや NDA を締結した選管の選定も必要ですし… 財団が実施した投票（理事選挙やライセンス投票など）以外だと、enwp や fawp の裁定委員会委員選挙でしか使われている場面を見たことがないです。余談: enwp 裁定委員会委員選挙の選管はスチュワードです。--rxy（会話） 2017年10月25日 (水) 00:32 (UTC)

よくよく考えてみたら丁度500なので投稿記録で最古の500件出せば簡単にわかりますね（自分は487回でした）。

投票も、そもそも普通だったら誰がどれに投票したかは秘密であるべきですよね。今回のような大規模な変更に限らず、信任/解任投票等のそれなりに機密性が必要な場面でもっと手軽に（Twitterのアンケートくらいのハードルで）暗号投票が使えたらいいと思うのですが…。一度仕組みを整えてしまえば簡単に使えるのかと思いましたが、Wikitech:SecurePollあたりを見る限り難しそうですね。別件として議論すれば本格的に導入できるかもしれませんが、ハードル高そうですね…。あまり関係ない話なのでこの辺にしておきます。--ひむちや (会話/投稿記録) 2017年10月25日 (水) 09:23 (UTC)

「2017/8/17 0:00(UTC)時点で初回編集から3ヶ月、500編集以上」…　初編集が　2017/5/17 0:00(UTC) よりも前 (or 以前?) で、2017/8/17 0:00(UTC)時点 で 500 編集あればよいのですね？　投票資格文案: 「ウィキペディア日本語版において、次の条件をすべて満たす登録利用者。投票時点において 特別:投稿記録 に掲載されている全名前空間での編集で (1) 初回編集が 2017/5/17 00:00:00(UTC) よりも前 (2) 2017/8/17 00:00:00(UTC) 以前の投稿回数が 500 編集以上」など ; 成立条件、どうします?　このページではそういった文言は一切見当たらないのですが。 ; 投票方法についても、30日なら賛成だけど 120日になるくらいなら導入自体に反対、といったことも想定されうると思います。一回の投票で済ませようとするのは無理があるのではないでしょうか。回数と日数については事前に簡単な調査投票で候補を一本化し、最終投票で賛否を問う方が各投票者の意思を賛否 / 5者択一方式よりもくみ取れるのではないかと考えます。--rxy（会話） 2017年10月25日 (水) 00:32 (UTC)

回数に関しては、『５００回に賛成かどうか』ですので、反対意見が出ない限り、問題は無いかと思います。

日数についてですが、『単なる思いつきを、ブレインストーミング的に』書いてみますが。廃案も含めて５つの案とした上で、許容できるというか、賛成できるというか、反対しないというか、そういう案を挙げるというのはどうでしょうか？

廃案と３０日に賛同した場合、３０日で有れば賛同だけど、それ以上の日数になるなら反対、という感じですね。ただし、賛成派が廃案を除くすべてに賛同意見を投じては問題が有りそうですので、３票まで表明できる(廃案に３票とか、１２０日に３票とかも、可能)としてはどうでしょうか？　それで、一番数が少ない案を除いて、今度は２票まで表明。その次も、一番数が少ない案を除いて、今度は１票だけ表明。最後に、一番数が少ない案を除いて、どちらに賛成かを表明。みたいな感じで。

尚、『あくまでも、単なる思いつきですので、使えるのであれば参考にして欲しい』というだけです。『使えないなら、スルーで構いません』し、このやり方を提案する、という程の意思は有りません。--ただのしかばね（会話） 2017年10月25日 (水) 02:03 (UTC)

僅差で競るかもしれないことを考慮すれば、投票を二段階にすること自体はありかもしれません。しかし『30日なら賛成だけど 120日になるくらいなら導入自体に反対』のような意見を投票で汲み取るのは、（択一にしようが複数選択にしようが二段階の投票にしようが）かなり難しいのではないでしょうか。多少は妥協せざるを得ないのではないと思います。

成立条件とは何を指しています？RFAで言うところの75%以上のような基準のことですか？--Marine-Blue^{talk✿contribs❀mail} 2017年10月26日 (木) 14:01 (UTC)

二段階投票 > 最初は一つの案が特定割合を得られるまで下位の候補を削って絞っていく 決選投票 方式が望ましいとは思ったのですが、これはあまりにも手間がかかりすぎると思い、2段階くらいなら許容可能かなー　というのが私の意見です。「30日なら賛成だけど 120日になるくらいなら導入自体に反対」という場合、二回に分ければある程度は（厳密にではなくても）意見はくみ取れると思います。一回目の条件策定のための調査投票段階で30日に投票した人が、120日が本投票の際の案となった場合、反対を表明する機会が得られます。 ;　成立条件 > そうです。Wikipedia:井戸端/subj/半保護の期間を英語版同様の「登録から4日かつ10編集」に変更する提案/投票所#投票所　「案の成立基準」に書いてあるようなことです。--rxy（会話） 2017年10月26日 (木) 16:39 (UTC)

コメント 3点確認したいことがあります。「運用ルールは投票進行とは別途で検討を行います。」とのことですが、これは①投票で本機能の導入が決まったとしても運用ルールについての別途の検討が行われ運用ルールが決定するまでは拡張半保護は使わない②運用ルールの検討の段階で意見が割れる等して合意できなければ「拡張半保護を機能としては導入したけれども、運用としては使用しない」という選択肢もありえる、との理解でよろしいでしょうか？投稿回数500回の条件は「新規記事作成や既存記事の大幅な加筆をメインに活動する執筆者にとってハードルが高すぎる」と感じますし（私の履歴で、削除依頼等にもそれなりに関わった上でも500編集まで約7ヶ月、標準名前空間だけなら15ヶ月もかかっています）、一方でその気になって編集回数を稼ぐならそこまで高いハードルだとは思えないのですね。寝かしアカウント対策を考えれば編集回数の条件を高くせざるを得ないのは分かりますし、そこは運用（必要に応じて拡張保護ページの編集依頼や能動的な編集権限付与のシステム整備など）で対応するのが一番いいのだとは思いますが、「運用の議論は別途」である以上は「機能としては実装されても運用面で折り合いがつかなければ使わない」という選択肢は担保されていて欲しいと感じます。逆に、しっかりと運用面でのフォローができるのであれば、投稿回数1000回～もっと多くの所で設定したとしてもあまり問題は生じないのではないかとも感じています。そう考えると、③拡張半保護機能導入後に編集回数等の条件の変更は可能かどうかという点が気にかかります。もうここで500回と決めてしまったら後はもう変更が出来ない、もしくは変更には再度投票を行ってシステム管理者に変更を依頼してといったような多大な手間がかかるということになるのでしょうか？もう少し簡単に条件変更がきくのであれば、ひとまず500回でやって様子を見て回数を増やす減らすという議論もやりやすいかと思いますが、その辺りはどうなのでしょう？--重陽（会話） 2017年10月28日 (土) 15:01 (UTC)

コメント （rxyさん宛て）積極的な支持こそしませんが、二段階の投票のほうがより適切な結果が得られるだろうというのであればそれでも構いません。

票数の割合は…半保護の仕様変更提案のときのようにSitenoticeなどで告知して投票を実施するのであれば、賛成する側の票の合計が75%以上（反対票が25%未満）で良いと思います。あとは票が多い択を採用（一時投票で二つ、二次投票で一つ）していく感じで。Sitenoticeなどの大きな全体告知はなしで投票すべきだという場合に限り、細々とした投票を想定して条件を緩くします。

（重陽さん宛て）方針と投票を切り分けたのは単純に、話が頓挫することを防ぐことが目的です。方針が決まるまで投票しないというやり方を取ると、議論が頓挫しかねないからです。また、方針が決まるまで使うべきではないのは当然でしょう。そもそも無期限全保護の回避手段であるため、半保護の感覚で使って良い代物ではありません。

回数の変更はシステム管理者へ依頼を飛ばすことにはなります。半保護と同じです。必要もなく制約を受けるユーザーが出てくるのは、回数をいくらにしたところで同じことです。そこで、巻き添えを食う利用者を可能な限り救済するため、能動的な付与という機能を設けるようにしています。個人的にはIPブロック適用除外のような、管理者裁量も欲しいところです。--Marine-Blue^{talk✿contribs❀mail} 2017年10月28日 (土) 17:58 (UTC)

返信 (Marine-Blueさん宛) 二段階賛否方式でも一段階多肢選択法でもいいですが、私としては拡張半保護を確実に導入したいなら投票者に導入条件が分かりやすい二段階賛否方式での投票をお勧めします。一度目の条件設定調査投票は小規模で行って、実装のための本投票のみ sitenotice でログイン利用者へ告知すればよいかと思います。私は導入されてもされなくても気にしないので、導入したい方々の都合の良い方法でやってもらえばいいと思います。成立条件については異存ありません--rxy（会話） 2017年10月28日 (土) 21:33 (UTC)

返信 (重陽さん宛) 3 について技術的な観点でのコメント: 一度設定した条件を引き下げる場合はそこまで技術的・運用的懸念事項はありませんが、引き上げの場合は少々厄介な事態になります。Marine-Blue さんが今回提案されている英語版の拡張半保護方式の場合、拡張半保護条件を満たさない利用者が「最終編集時点で拡張半保護の利用者足りうるのか」を判定し、真となった場合には昇格します。しかしながら、何らかの都合で拡張半保護編集権限取得条件を引き上げたとしても、既に昇格されて拡張半保護されたページの編集が可能な利用者は、新条件に満たなくてもそのまま拡張半保護されたページの編集が可能になります。もちろん放置しておくのもありですが、もし新条件に満たない利用者から拡張半保護権限を剥奪するとなると、一度剥奪された利用者は新たに引き上げられた条件に達しても再び翔鶴することはありません。なぜなら、こうしなければ別件で剥奪された人が編集のたびに再昇格してしまうからです。自動で再昇格されるようにする場合、データベース管理者に「新条件不達のために剥奪した人」が再昇格できるように本番データベースで特定クエリ（`user_former_groups` テーブルから新条件不達のために剥奪した人に関連付く値 'extendedconfirmed' のあるレコードを削除してもらう）を実行してもらう必要が生じます。また、設定変更依頼の場合、新たに大規模な投票をする必要まではありませんが、やはり設定変更のための合意は必要です。--rxy（会話） 2017年10月28日 (土) 21:33 (UTC)