コンテンツにスキップ

「Wikipedia:井戸端/subj/拡張半保護の導入」の版間の差分

削除された内容 追加された内容
→‎コメント: 基準地点等に関する解説
99行目: 99行目:
*** {{コメント}} <del>投票資格を500編集にした場合の懸念として、採用された場合に自動承認される利用者のみの投票となることで、後になって「自分達に都合が良い条件を少数で決めた」という印象を抱かれないかという事があります。</del>管理者の信任や解任などの投票権に合わせれば、直近編集条項があるので長期荒らしによる多重投票の可能性は少ないのではないかと思います--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月5日 (日) 12:00 (UTC){{small|勘違いしていたかもしれない部分を取り消し--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 06:45 (UTC)}}
*** {{コメント}} <del>投票資格を500編集にした場合の懸念として、採用された場合に自動承認される利用者のみの投票となることで、後になって「自分達に都合が良い条件を少数で決めた」という印象を抱かれないかという事があります。</del>管理者の信任や解任などの投票権に合わせれば、直近編集条項があるので長期荒らしによる多重投票の可能性は少ないのではないかと思います--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月5日 (日) 12:00 (UTC){{small|勘違いしていたかもしれない部分を取り消し--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 06:45 (UTC)}}
**** {{コ|質問}} 拡張半保護の導入前から登録している利用者の自動<del>昇格</del><ins>付与</ins>の基準は、どうなるのでしょうか?拡張半保護の導入時点からの算出であれば、私の書いた懸念は的外れだったということになります--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 06:45 (UTC){{small|用語訂正--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 07:44 (UTC)}}
**** {{コ|質問}} 拡張半保護の導入前から登録している利用者の自動<del>昇格</del><ins>付与</ins>の基準は、どうなるのでしょうか?拡張半保護の導入時点からの算出であれば、私の書いた懸念は的外れだったということになります--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 06:45 (UTC){{small|用語訂正--[[利用者:Aki42006|aki42006]]([[利用者‐会話:Aki42006|会話]]) 2017年11月6日 (月) 07:44 (UTC)}}
***** 本投票を実施して成立し、拡張半保護が実装された後の話と仮定します。拡張半保護権限自動付与における編集回数は [[Special:Preferences#mw-htmlform-info]] に記載されている編集回数が基準になります。[[special:diff/66096508]] にも書きましたが、最終編集実施時点において「拡張半保護編集権限」を持っておらず、かつ個人設定記載の編集回数が拡張半保護自動付与条件の編集回数以上であり、かつアカウント作成から指定秒数以上経過していて、かつ過去に権限が除去された記録がデータベース上になければ、付与されます。拡張半保護編集権限の基準地点は「アカウント作成以後すべての編集」となります。この基準地点を拡張半保護導入以後にすることは現状だと特別な実装をしない限りできません。--[[利用者:Rxy|rxy]]([[利用者‐会話:Rxy|会話]]) 2017年11月6日 (月) 10:52 (UTC)
*** {{コ}} 個人的には事前議論への参加は自由だったわけですから「影響を受けない少数のユーザーだけで決めた」ことにはならないと思うのですが。影響の非常に大きい提案ですから投票資格を厳しく設定するのは当然のことですし、投票資格のない方でもコメント資格までない訳ではないでしょう。気になる方が多いようでしたら「拡張半保護」と一致する「500編集」を条件にするのを避けてRfaに準拠する分には問題ないかと思いますが、直近編集条項ありだと分かりにくくて参加しづらいという方もいるかもしれませんね。--[[利用者:SilverSpeech|SilverSpeech]]([[利用者‐会話:SilverSpeech|会話]]) 2017年11月6日 (月) 04:08 (UTC)
*** {{コ}} 個人的には事前議論への参加は自由だったわけですから「影響を受けない少数のユーザーだけで決めた」ことにはならないと思うのですが。影響の非常に大きい提案ですから投票資格を厳しく設定するのは当然のことですし、投票資格のない方でもコメント資格までない訳ではないでしょう。気になる方が多いようでしたら「拡張半保護」と一致する「500編集」を条件にするのを避けてRfaに準拠する分には問題ないかと思いますが、直近編集条項ありだと分かりにくくて参加しづらいという方もいるかもしれませんね。--[[利用者:SilverSpeech|SilverSpeech]]([[利用者‐会話:SilverSpeech|会話]]) 2017年11月6日 (月) 04:08 (UTC)

2017年11月6日 (月) 10:52時点における版

拡張半保護の導入

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

1.導入の目的
寝かしアカウントによる半保護突破編集への抑止策。
現状、半保護突破編集を阻止する手段が全保護しかなく、全保護されると無害な利用者の編集さえも禁止することになるため。
2.導入する機能
半保護と全保護の中間にあたる保護区分で、ある程度長期的に活動する利用者のみに編集を許可する。
3.承認条件
指定日数以上活動し、指定回数以上の編集を行ったユーザーのみが編集できる。能動的な承認/承認取り消しも可能にしておく。
(指定条件を満たすユーザーには自動的に「拡張承認された利用者」のフラグが付与され、指定条件を満たさないユーザーを敢えて承認する必要が生じればIPブロック適用除外のような感じでフラグを付与できます。)

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

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

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

また、念のため再度申し上げますが、運用ルールは投票進行とは別途で検討を行います。フラグの与奪基準など、ルールの話と導入自体に賛成/反対をここでいっぺんに行ってもグダグダになるだけです。今回の目的は「仕様を決めてシステム管理者に申請を行うこと」です。今回はこの「拡張半保護」が必要だと思ったら賛成、不要だと思ったら反対ということです。--Marine-Bluetalkcontribsmail 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-Bluetalkcontribsmail 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時点で500回以上編集されている方は、資格が有ると解釈できます。
(もし違うので有れば、速やかに訂正されるべきかと思います。)--ただのしかばね会話2017年10月24日 (火) 14:09 (UTC)[返信]
皆様コメントありがとうございます。しばらく考えてみたところ、投票資格は捻り過ぎな気がしてきました。シンプルに「2017/8/17 0:00(UTC)時点で初回編集から3ヶ月500編集以上」でも十分に休眠アカウントの議論妨害を防ぐ目的は達成できるし、(相対的に見れば)無効票確認もしやすいでしょう。というわけで投票資格を「2017/8/17 0:00(UTC)時点で初回編集から3ヶ月、500編集以上」にしようかと思うのですが、よろしいでしょうか。--Marine-Bluetalkcontribsmail 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)[返信]
コメント 回数に関しては、『500回に賛成かどうか』ですので、反対意見が出ない限り、問題は無いかと思います。
日数についてですが、『単なる思いつきを、ブレインストーミング的に』書いてみますが。廃案も含めて5つの案とした上で、許容できるというか、賛成できるというか、反対しないというか、そういう案を挙げるというのはどうでしょうか?
廃案と30日に賛同した場合、30日で有れば賛同だけど、それ以上の日数になるなら反対、という感じですね。ただし、賛成派が廃案を除くすべてに賛同意見を投じては問題が有りそうですので、3票まで表明できる(廃案に3票とか、120日に3票とかも、可能)としてはどうでしょうか? それで、一番数が少ない案を除いて、今度は2票まで表明。その次も、一番数が少ない案を除いて、今度は1票だけ表明。最後に、一番数が少ない案を除いて、どちらに賛成かを表明。みたいな感じで。
尚、『あくまでも、単なる思いつきですので、使えるのであれば参考にして欲しい』というだけです。『使えないなら、スルーで構いません』し、このやり方を提案する、という程の意思は有りません。--ただのしかばね会話2017年10月25日 (水) 02:03 (UTC)[返信]
コメント 僅差で競るかもしれないことを考慮すれば、投票を二段階にすること自体はありかもしれません。しかし『30日なら賛成だけど 120日になるくらいなら導入自体に反対』のような意見を投票で汲み取るのは、(択一にしようが複数選択にしようが二段階の投票にしようが)かなり難しいのではないでしょうか。多少は妥協せざるを得ないのではないと思います。
成立条件とは何を指しています?RFAで言うところの75%以上のような基準のことですか?--Marine-Bluetalkcontribsmail 2017年10月26日 (木) 14:01 (UTC)[返信]
二段階投票 > 最初は一つの案が特定割合を得られるまで下位の候補を削って絞っていく 決選投票 方式が望ましいとは思ったのですが、これはあまりにも手間がかかりすぎると思い、2段階くらいなら許容可能かなー というのが私の意見です。「30日なら賛成だけど 120日になるくらいなら導入自体に反対」という場合、二回に分ければある程度は(厳密にではなくても)意見はくみ取れると思います。一回目の条件策定のための調査投票段階で30日に投票した人が、120日が本投票の際の案となった場合、反対を表明する機会が得られます。 ; 成立条件 > そうです。Wikipedia:井戸端/subj/半保護の期間を英語版同様の「登録から4日かつ10編集」に変更する提案/投票所#投票所 「案の成立基準」に書いてあるようなことです。--rxy会話2017年10月26日 (木) 16:39 (UTC)[返信]
今回の拡張半保護を重半保護とした場合に、重半保護と現行半保護の中間の「中間半保護」(仮に30日100編集としましょうか)を導入したら解決する事案かもしれません。重すぎる半保護が嫌だとする意見が多い場合は(とりあえず、一段階増やす提案なのは承知の上で、意見が2分されるようであれば、柔軟な対応を考えてはの意味です)。--Taisyo会話) 2017年10月30日 (月) 23:46 (UTC) , 追記--Taisyo会話2017年10月31日 (火) 03:13 (UTC)[返信]
コメント 3点確認したいことがあります。「運用ルールは投票進行とは別途で検討を行います。」とのことですが、これは①投票で本機能の導入が決まったとしても運用ルールについての別途の検討が行われ運用ルールが決定するまでは拡張半保護は使わない②運用ルールの検討の段階で意見が割れる等して合意できなければ「拡張半保護を機能としては導入したけれども、運用としては使用しない」という選択肢もありえる、との理解でよろしいでしょうか?投稿回数500回の条件は「新規記事作成や既存記事の大幅な加筆をメインに活動する執筆者にとってハードルが高すぎる」と感じますし(私の履歴で、削除依頼等にもそれなりに関わった上でも500編集まで約7ヶ月、標準名前空間だけなら15ヶ月もかかっています)、一方でその気になって編集回数を稼ぐならそこまで高いハードルだとは思えないのですね。寝かしアカウント対策を考えれば編集回数の条件を高くせざるを得ないのは分かりますし、そこは運用(必要に応じて拡張保護ページの編集依頼や能動的な編集権限付与のシステム整備など)で対応するのが一番いいのだとは思いますが、「運用の議論は別途」である以上は「機能としては実装されても運用面で折り合いがつかなければ使わない」という選択肢は担保されていて欲しいと感じます。逆に、しっかりと運用面でのフォローができるのであれば、投稿回数1000回~もっと多くの所で設定したとしてもあまり問題は生じないのではないかとも感じています。そう考えると、③拡張半保護機能導入後に編集回数等の条件の変更は可能かどうかという点が気にかかります。もうここで500回と決めてしまったら後はもう変更が出来ない、もしくは変更には再度投票を行ってシステム管理者に変更を依頼してといったような多大な手間がかかるということになるのでしょうか?もう少し簡単に条件変更がきくのであれば、ひとまず500回でやって様子を見て回数を増やす減らすという議論もやりやすいかと思いますが、その辺りはどうなのでしょう?--重陽会話2017年10月28日 (土) 15:01 (UTC)[返信]
コメント (rxyさん宛て)積極的な支持こそしませんが、二段階の投票のほうがより適切な結果が得られるだろうというのであればそれでも構いません。
票数の割合は…半保護の仕様変更提案のときのようにSitenoticeなどで告知して投票を実施するのであれば、賛成する側の票の合計が75%以上(反対票が25%未満)で良いと思います。あとは票が多い択を採用(一時投票で二つ、二次投票で一つ)していく感じで。Sitenoticeなどの大きな全体告知はなしで投票すべきだという場合に限り、細々とした投票を想定して条件を緩くします。
(重陽さん宛て)方針と投票を切り分けたのは単純に、話が頓挫することを防ぐことが目的です。方針が決まるまで投票しないというやり方を取ると、議論が頓挫しかねないからです。また、方針が決まるまで使うべきではないのは当然でしょう。そもそも無期限全保護の回避手段であるため、半保護の感覚で使って良い代物ではありません。
回数の変更はシステム管理者へ依頼を飛ばすことにはなります。半保護と同じです。必要もなく制約を受けるユーザーが出てくるのは、回数をいくらにしたところで同じことです。そこで、巻き添えを食う利用者を可能な限り救済するため、能動的な付与という機能を設けるようにしています。個人的にはIPブロック適用除外のような、管理者裁量も欲しいところです。--Marine-Bluetalkcontribsmail 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)[返信]
コメント では、最初の投票に大規模な告知はいらないだろうということであれば、最初は賛成側が過半数で、二度目は75%で成立にしようかと思います。
500編集に関しては、反対しない人もおられるため、あまり意見が出ないようであれば、申し訳ありませんがこのまま進めることになります。また、最初の投票前に方針ページも作成する予定です。議論の分散を避けるため今まで方針のページを作成せず進行しておりましたが、投票を開始するとなれば、投票ついでに意見をくださる方もおられると考えております。--Marine-Bluetalkcontribsmail 2017年10月30日 (月) 17:17 (UTC)[返信]
返信 ご返答ありがとうございます。運用の議論を別途とすることに対して異論があるわけではなく、方針と投票が切り分けられるからこそ確認したいという事でした。投票で拡張半保護機能が導入された後も、運用が合意されるまでは使わない、運用が合意できなければ使わないということで承知いたしました。Marine-Blueさんにとっては当然のことだったかもしれませんが、はっきり言葉にしていただきましたことで議論参加者および投票参加者全体で共有できたかと思います。回数の変更に関してはMarine-Blueさんだけでなくrxyさんからもシステム面から説明いただきましてありがとうございました。議論をして合意形成すれば回数を減らすことは可能であり、回数を増やす場合は技術面や運用面でハードルが高いが高いという点、非常によく分かりました。とはいえ更に回数を増やすのはよっぽどの問題が出たときでしょうし、回数を増やさないといけないほどの問題があるならその厄介な事態に直面してでも対応しないと仕方ないでしょうから、巻き添え利用者の救済は能動的付与などの運用面できっちり対応していただけることを期待して、とりあえず500回で実装ということで異論ありません。ありがとうございました。--重陽会話2017年10月30日 (月) 22:14 (UTC)[返信]
  • 私も確認したいと思います。以前私が主導の形で行ったWikipedia:井戸端/subj/半保護の期間を英語版同様の「登録から4日かつ10編集」に変更する提案Wikipedia:井戸端/subj/半保護に可変設定機能を追加することについてで得られた情報なのですが、「半保護=自動承認された利用者のみ許可」と認識しております。当然ではありますが、今回導入される重半保護(拡張半保護)は「拡張半保護=経験の長い利用者のみ許可」みたいな形になると思いますが、その分だけ保護のセレクターが「全ての利用者の許可」・「自動承認された利用者のみ許可」・「管理者のみ許可」に加えて追加されると思ってよろしいでしょうか。4つ程度でしたら混乱しないのですが、以前話に出てきた軽半保護(今だったら、4日経過したら許可)などや、重々半保護(1年かつ2000編集など)追加されるときに混乱が予想されます。当面は無いにしても、現状の保護に関するインターフェイスが変わる予定とかあるのでしょうか。--Taisyo会話2017年10月30日 (月) 22:58 (UTC)[返信]
    • コメント はい、そのご認識で相違ございません。保護インターフェースの変更は 編集画面や 特別:ブロック などの刷新と同様にそう遠くない未来、mw:OOUI ベースに置き換えられるものと思われます。phab:T117722, phab:T107037, phab:T100161--rxy会話2017年10月30日 (月) 23:12 (UTC)[返信]
      • コメント ありがとうございます。もう一つ以前の議論の疑問で出てきたのですが、以前既存の物より重たい半保護を導入しようとしたときに、メタの権限で重半保護の対応が出来ないことで反対意見が実際に出ました(個人的に、当時も現在も重半保護導入賛成派ですし、英語版よりも進んだシステムを導入するチャンスとも考えております)。今回は、英語版で重半保護が導入済みである事や統一ログインの導入などで、重たい半保護を導入しても大丈夫となった認識で大丈夫でしょうか。もし仮に、英語版よりも利用者権限を増やした場合に、統一ログイン導入によりメタ権限での保護記事編集に支障は無い(わざわざ、メタの人が一時的に日本語版の管理者になる必要が無い)と考えて良いですか。--Taisyo会話2017年10月31日 (火) 10:24 (UTC)[返信]
        • はい、対応可能です。拡張半保護分は既にスチュワード等が問題なく編集できるようになっていますね。新たに設定した場合はグローバル権限の方にその別途追加した保護レベルの編集ができる権限をつけることになります。まあ、(保護には全く関係ないですが)グローバル権限でどうにもならなければ勝手に管理者権限やローカルでスチュワード権限をつけてどうにかすることになりますが(例えば特定利用者への拡張保護編集権限与奪は meta ではできなくて、何らかの理由でそれをスチュワード等が必要とする場合)。--rxy会話2017年10月31日 (火) 10:57 (UTC)[返信]

久しぶりに井戸端を見たところ、妙な議論が行われているので投稿します。特に気になるのは、投票資格を500回以上投稿したアカウントユーザーに限ろうとしている点です。というのは、この投票条件だと投票できるのは拡張半保護の仕組みができても影響を受けないアカウントユーザーに限られてしまうからです。つまり、この投票で賛成が多数であっても、「一部の利用者が自分たちだけで自分たちに都合の良いルールを決めた」ことになってしまうので、成立過程の正当性に疑問が生じてしまうからです。私のようなIPユーザーを含めると票数の計算ができなくなるので投票資格をアカウントユーザーに限ることに異議を唱えるつもりはありませんし、そもそも私にとっては半保護も拡張半保護も同じことなので、投票できないことは全く問題ではありませんが、この提案には投票の正当性に関する観点が抜けていると思います。126.92.45.70 2017年11月1日 (水) 16:06 (UTC)[返信]

  • コメント こちらのIPさんと同意見です。本件について、新しい対応が必要になっているいるのは理解しますが、その決定に「投票資格を500回以上投稿したアカウントユーザー」と制限するのには、違和感を感じます。投稿ブロック依頼でも、50回程度なので500回は多すぎと感じます。時々、加筆修正したり、記事の新設をしたりしている人に配慮が足りないと思います。(一応ですが、私は導入自体には賛成です。)--Pengin会話2017年11月3日 (金) 05:49 (UTC)[返信]
    • コメント 投票資格に関しては、善意の新規利用者を装った不正な多重アカウント利用者をなるべく排除できる条件設定が必要不可欠であると考えております。意図的に高い条件設定を行ったのもこのためです。投票資格の投稿回数に関しては変えても構いませんが、不正投票を可能な限り排除するためという目的だけは徹底したいところです。少なくとも、ブロック依頼よりは高い条件設定が必要だと思います。新規利用者も可能な限り参加させて不正投票なんてCUで調べれば良いと思う方がいらっしゃるかも分かりませんが、CUで必ずしも不正が見抜けるとは限りません。なお、不正投票防止という目的にかなったものであれば、別案は歓迎します。--Marine-Bluetalkcontribsmail 2017年11月3日 (金) 07:16 (UTC)[返信]
    • コメント 私が思うに、相当な炎上騒動(最近でいえば、角川の一件)などがなければ、寝かしアカウントを動かす人はいないと思っています。こういった投票にわざわざ寝かしアカウントを動かしてまで対抗するする人はいないと思います。なので、投稿数制限はやりすぎな気もします。せめて、過去に事例がないので事前に投票で同意を集めたほうがいいと思います。また、反対票に理由をつけることを必須にするのであれば、多重投票等を抑えられるのではないかという気もします。--Pengin会話2017年11月3日 (金) 09:57 (UTC)[返信]
  • コメント 126.92.45.70 あらため 126.109.134.42 です。前回も書いたように、この提案は私にとって全く影響のない提案なので、利害関係のない立場でコメントします。管理者の信任投票の基準が50なのにいきなり500というのはやはり違和感があります。そこで、(思い付き程度の提案ですが、)とりあえず50回以上の投稿者を有権者として500でよいかどうか予備投票をしてみるというのはいかがですか。投票の有権者が多ければ多いほど投票自体の権威(?)が高まるので、自動承認されたアカウントユーザー全員を対象として500でよいかどうかの予備投票を行うというのでも良いかもしれません。どうもmarine-Blueさんが心配しておられることは杞憂のように思うのですが、予備投票をしてみれば杞憂であることがはっきりするような気がします。(もちろん杞憂でないことがはっきりする可能性もあるわけですが、そのときはそのときということで。)126.109.134.42 2017年11月3日 (金) 10:28 (UTC)[返信]
  • コメント ふと思ったのですが、『管理者の解任規定の濫用を防ぐため』となっている『管理者の解任の動議提出権者』でさえ、編集回数は150回です。ですので、そう考えると確かに、500回というのは過剰かも知れません。
そして、単なる思いつきなのですが、『管理者の解任の動議提出権者』と同じ条件、というのはどうでしょうか? 3か月=2017/07/23 00:00以前に初編集、という事で。これならば、上記動議提出権者の条件に準じたという事で、反対も出にくいとは思うのですが。(出ないとまでは思ってません)
尚、ブレインストーミング的に書いてみただけの案ですので、提案という程の意思は有りません。ダメならスルーでOKです。--ただのしかばね / / 2017年11月3日 (金) 11:33 (UTC)[返信]
コメント 言い忘れです。『提出時から遡って直近1か月間の標準名前空間の編集回数が10回以上』ですので、単純に編集回数を高く設定するよりも、『寝かし』への対策としては、有効かも知れません。また、『こちらのページ』のURLの僕の名前を、該当する方の名前に置き換えれば、その確認はできると思います。
(条件を、上記動議の投票権者に揃えた場合でも、使えるかと思います。)--ただのしかばね / / 2017年11月3日 (金) 11:56 (UTC)[返信]
 追記 何度もスミマセン。上記コメント後、ふと思って確認した所。この条件だと、提案者ですら投票権がないという事になってしまいますね。ですので、上記動議の投票権者に揃える感じで良い気がしてきました。(というか、そうしないと誰かが今回の提案を引き継がないといけない、という事になります。僕は、そんなの出来る習熟度じゃないですし。)--ただのしかばね / / 2017年11月3日 (金) 12:03 (UTC)[返信]
  • コメント 投票資格を、管理者の信任や解任などの投票権者に合わせる案に賛成します。起点は2017/8/17 0:00(UTC)で良いと思います--aki42006会話2017年11月4日 (土) 06:31 (UTC)[返信]
    • コメント けもフレ騒動で俄かに出てくるようなユーザーは気にしなくて良いと考えております。そのようなユーザーは投票ページの半保護で対応すれば済みます。私が警戒すべきと考えているのは、休眠アカウントを動員して半保護を突破し、全保護の要因を作るようなユーザー(主に長期荒らし)です。つまりこの拡張半保護で規制されるべきユーザーと言えばご理解いただけるでしょうか。長期荒らしの場合、50編集を突破できるケースはときどきあるので、動議提出権に合わせたほうがまだ無難だと思います。--Marine-Bluetalkcontribsmail 2017年11月5日 (日) 07:38 (UTC)[返信]
      • コメント 直近編集条項がないなら 500, あるなら RfA 投票資格準拠でもいいと思いますが、個人的には直近編集条項なしの方がわかりやすい気がします。--rxy会話2017年11月5日 (日) 07:50 (UTC)[返信]
      • コメント 以前のコメント直下に書いてはないですが、コメント内容が私宛のように思うのでコメントします。(間違っていたらすみません)
        一応ですが、上のコメントは過去にない事例の投票制限は事前承認なしで作るべきではないと思いコメントしました。管理者解任関連の投票数が、150回ということを知らなかったので自分が知っている最大数の50回としていました。150回であれば、投票制限をかけてもいいのではないでしょうか。ただ、ひとつだけあるとすれば、通常時使用されている投票制限を上回る投票制限を設ける場合、既存の投票制限以下の基準でその基準の確認を行う事前投票をするべきではないかと思います。--Pengin会話2017年11月5日 (日) 09:34 (UTC)[返信]
      • コメント 投票資格を500編集にした場合の懸念として、採用された場合に自動承認される利用者のみの投票となることで、後になって「自分達に都合が良い条件を少数で決めた」という印象を抱かれないかという事があります。管理者の信任や解任などの投票権に合わせれば、直近編集条項があるので長期荒らしによる多重投票の可能性は少ないのではないかと思います--aki42006会話) 2017年11月5日 (日) 12:00 (UTC)勘違いしていたかもしれない部分を取り消し--aki42006会話2017年11月6日 (月) 06:45 (UTC)[返信]
        • コメント 質問 拡張半保護の導入前から登録している利用者の自動昇格付与の基準は、どうなるのでしょうか?拡張半保護の導入時点からの算出であれば、私の書いた懸念は的外れだったということになります--aki42006会話) 2017年11月6日 (月) 06:45 (UTC)用語訂正--aki42006会話2017年11月6日 (月) 07:44 (UTC)[返信]
          • 本投票を実施して成立し、拡張半保護が実装された後の話と仮定します。拡張半保護権限自動付与における編集回数は Special:Preferences#mw-htmlform-info に記載されている編集回数が基準になります。special:diff/66096508 にも書きましたが、最終編集実施時点において「拡張半保護編集権限」を持っておらず、かつ個人設定記載の編集回数が拡張半保護自動付与条件の編集回数以上であり、かつアカウント作成から指定秒数以上経過していて、かつ過去に権限が除去された記録がデータベース上になければ、付与されます。拡張半保護編集権限の基準地点は「アカウント作成以後すべての編集」となります。この基準地点を拡張半保護導入以後にすることは現状だと特別な実装をしない限りできません。--rxy会話2017年11月6日 (月) 10:52 (UTC)[返信]
      • コメント  個人的には事前議論への参加は自由だったわけですから「影響を受けない少数のユーザーだけで決めた」ことにはならないと思うのですが。影響の非常に大きい提案ですから投票資格を厳しく設定するのは当然のことですし、投票資格のない方でもコメント資格までない訳ではないでしょう。気になる方が多いようでしたら「拡張半保護」と一致する「500編集」を条件にするのを避けてRfaに準拠する分には問題ないかと思いますが、直近編集条項ありだと分かりにくくて参加しづらいという方もいるかもしれませんね。--SilverSpeech会話2017年11月6日 (月) 04:08 (UTC)[返信]