Wikipedia:井戸端/subj/「承認された利用者」についての再議論

井戸端のタグ：保護 | 半保護 [編集]

「承認された利用者」についての再議論

目次

「承認された利用者」、"lowprotect"、"highprotect" について、議論以来放置されているので、ここで再議論を行います。議論は#本議論で行ってください。--蝦夷(EZO) from 涿県 2012年1月22日 (日) 06:07 (UTC)

前回の議論

Wikipedia:井戸端/subj/半保護に可変設定機能を追加することについて

半保護に可変設定機能を追加することについて

現在、半保護に関して、IPユーザー及び新規登録4日までのユーザーに対して機能する様になっております。デフォルト設定に関しては現行のままで行うとして、可変設定の形で新規登録ユーザーの登録日数の可変（設定方法によっては、IPユーザーのみの制限にする事も出来る）・投稿数による制限など追加出来ないかどうか思いました。導入の賛否や運用など意見があれば頂きたいと思います。現状として、ブロック依頼や削除依頼での資格がないのに投稿する例があり、それらの対応には有効に思います。

また別の節で、技術的な問題についても確認したいと思います。もし仮に導入賛成が多数だとしても技術的に導入できない物であれば意味が無いので、それらの事情に詳しい方は別途意見をいただきたいと思います。また、日本語版以外での導入状況についても確認してもたいと思います。--Taisyo 2011年5月27日 (金) 11:21 (UTC)

賛否のみ意思表示

• コメント 議論に参加する予定はないけど、賛否を示したい方は以下にお願いします。--Taisyo 2011年6月2日 (木) 14:17 (UTC)

導入の是非についての議論

もし出来る物であれば、提案通り導入をして欲しい物だと思います。ルールについては、もう少し意見を集まった時点で考えたいと思います。--Taisyo 2011年5月27日 (金) 11:21 (UTC)

現在の技術上無理だとしても、仕様の拡張をお願いする事もあると思いますので（次回の拡張時に反映してもらう）、単純に「欲しい」「要らない」の意見でもそれなりに意味ある物だと思います。--Taisyo 2011年5月27日 (金) 13:50 (UTC)

私もアカウントを濫造し寝かせておくLTA対策として似たようなことを考えていました。新規登録からではなく、初編集から4日までのユーザーは半保護された記事は編集できないようにならないものかと。このようにすれば、LTAが執拗に編集を加える記事に対して全保護する必要はなくなり、半保護でよくなりますので、全保護しなければならない記事は減ると考えています。そういうことが技術的にできるのかどうかは確認して無いですが…。 --Haifun999 2011年5月27日 (金) 15:56 (UTC)

コメント 「半保護に可変設定機能を追加すること」についての技術的な問題は下に書いたとおりですが、技術的な実現可能性と実際の運用方法（規則）の難しさは別なのはご承知のとおりだと思います。下では可変設定にする以外の方法も提案されていますし、「半保護に可変設定機能を追加する」にこだわらず、何を目的としているのかをはっきりさせておいたほうが議論が拡散しないのかなと思いました。今のお話だとちょっと漠然としてしまっているのかな、と。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント 青子守歌さんに一番鋭い所を突かれたので。具体的には、現行ルールの限界と新規ルールでの向上点でしょうか。Haifun999さんの言うとおり、まず1番目は寝かしアカウントの対応です。私が初めて半保護を使用した際に、ネットニュースにも取り上げられるほどの事になった事を覚えております（結果として）。実際に、日本語版ではIPユーザーが多く、半保護は日本語版に適した機能であったと思います。4日間というのは、仮に編集したくてアカウントを作った所で、気持ちが落ち着く期間。心理的に効果的な対応法であったという事です。しかし、昨今のLTAの中には、半保護を回避する為に、アカウント作成後に寝かした上で使う行為が見受けられ、現実に疲弊する事態に陥っております。それらを解消する為には、半保護の拡張は有効ではないかと考えました。と、言いますと単純に期間長めの設定を追加するだけでも良いと解釈されるかもしれないです。

　そこで2つめの理由は、対応の柔軟化です。単純に条件を厳しくするのではなく、「IPユーザーも編集して良いけど、編集回数は下限が欲しい」・「IPユーザーのみ編集できない様にしたい」・「管理者立候補投票並みの基準を採用したい」など、場面により厳しくしたり、逆に緩めたりする運用をしたいと考えたからです。昨今の多重アカウントの改正でIPユーザーへの転向を考えるユーザーも現実におります。単に厳しくするのではなく、場面に合わせた設定の柔軟性が必要に感じたからです。

あと実際の運用としては、半保護を選択した時に「詳細設定をする」にマークを付けなかった場合は従来通り。付けた時に、いくつかの規定設定の選択が出来る様にする。その中に無い場合は詳細に期間・編集回数を設定する形になると思います。--Taisyo 2011年5月28日 (土) 11:23 (UTC)

コメント ログインユーザーである私には反対する理由はありません。問題は、締めだされる形のIPユーザーの権利はどの程度保護されるべきなのか？彼らに納得してもらえるのか？ということですね。理想を言えば、靴下などの問題行動が疑われるユーザーを選択的に制限する仕組みを作りたいものです。そういう意味で、海外版のen:Wikipedia:Pending changesに興味があります。個人的には可変IPの変動が激しくて悪用しやすいISP(例えばイーモバイル)を、選択的に条件を厳しくできるような仕組みができると嬉しいです--Littlefox

コメント 今回の提案で、全く荒らしが無くなるとは思ってはいないです。極力減らした上で、管理者がその抜け穴分をふさぐ形になると思います。数を現在より減らす事で対応しやすくなると思います。半保護の基準を厳しくする事で、荒らしユーザーにとって不利益になる。手間を掛けてアカウントを育てないといけない割には、出来る事は少ない。割に合わない状態にしていく事で、極力減らそうと考えたのが発想の原点です。もし仮に、半保護を「登録から1ヶ月かつ投稿数50」としたら、荒らしをするまでの手間が極端に増え、行為を行う人が減り、結果として減るのではと思います。それと、BOT的な編集をしたら目立ちますし、投稿時間もかかる。結果として真面目なユーザーに利になると思います。Littlefoxさんの話だと、おそらく「記事を限定してレンジブロックを入れる」だと思います。全体はこれまででもありますが、記事限定ではないと思います。もっとも、対応が難しくなりそうです。次の検討課題には悪くないと思います。--Taisyo 2011年6月1日 (水) 12:56 (UTC)

コメント 荒らしの中には、全保護を意図して荒らす例も存在しております。未保護・半保護・全保護の間のレンジがない以上仕方ない部分です。しかし、荒らしの意図の通りに保護になるのも荒らしの助長に繋がると思います。中間レンジがあれば、それも解消出来ると思います。--Taisyo 2011年6月2日 (木) 14:17 (UTC)

技術的な問題・日本語版以外での導入状況

実際に導入する時の仕様

これまでの議論を総合して以下の様な意見が出ております。

• （A案）現行半保護に、可変設定を追加する
• （B案）現行半保護とは別に、登録から20日かつ20投稿以上など厳しい基準の半保護2（仮称）を導入する
• （C案）現行半保護を、単純に厳しくする
• （D案）他の機能を活用して、実質的に厳しくする

--Taisyo 2011年6月4日 (土) 01:33 (UTC)

日本語版以外での半保護

Jkr2255さんの軽く調べた限りでは、「半保護でどのユーザーが編集できるか」の変更は出来るが、半保護に段階を設けることは現時点では不可能なようです。また、英語版で「登録から4日かつ10編集以下」とありますが、それは編集承認設定を変更する事で実現しているようです。--Taisyo 2011年5月28日 (土) 02:31 (UTC)

コメント 各言語版には各言語版の事情があるのでなんとも言えませんが、非アルファベット文字（≒非ヨーロッパ言語）の中で最大である日本語版のウィキペディアは、他の大きなウィキとはまた違った事情があるには間違いありません。bugzillaで探してみましたが、半保護に段階を設けてほしいというような要望自体出ていないようです。ですから、他言語版でないからといって萎縮する必要はないと思いました（ちょっとコメント場所違いかもしれませんが、ひとまずここで）。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント日本語圈のネットは海外より匿名文化の傾向が強いですからね。身元を特定されるリスクが大きいし、ユーザーもリスクを嫌う。おそらく、半保護について最も先進的な仕組みを作る必要がある言語圈だと思います（言論の自由が無い国を除く）--Littlefox 2011年6月1日 (水) 03:48 (UTC)体裁--Littlefox 2011年6月1日 (水) 03:50 (UTC)

コメント これまで英語版とかの仕組みを輸入してきましたが、今後は日本語版独自の仕組みも必要に思います。国民性・宗教性・法律など違う点は多いと思います。あと、良い物は他の言語版に輸出しても良いと思います。--Taisyo 2011年6月1日 (水) 13:04 (UTC)

編集フィルター

MediaWiki自体のサイトを軽く見てみましたが、「半保護でどのユーザーが編集できるか」は変えられるようですが、半保護に段階を設けることはできなさそうです。編集フィルターを使う場合は細かな設定ができうるので、そっちで処理を組み立てるのがいいのではないかと思います。--Jkr2255 (Talk/History) 2011年5月27日 (金) 13:14 (UTC)

軽く見た限りMediaWikiの仕様に無い件は了解しました。「半保護でどのユーザーが編集できるか」は、もしかしたら使えるかもしれないので、部分的な仕様拡張には使えるのかなと思いました。あと、編集フィルター色々調べてみます。ただ、全記事一律でかかる性格の物なので、例外の設定は慎重にしないといけないと思います（無理が有れば、その手も使えない事になりますので）。--Taisyo 2011年5月27日 (金) 13:50 (UTC)

少し考えたのですが、特定のテンプレートを作って、その文章で弾く形が出来るのかなと考えたりしております。信任を取る必要があるのであれば、研究の為にWikipedia:編集フィルター/権限付与の申請もしないといけないのかなと思っています。--Taisyo 2011年5月27日 (金) 16:10 (UTC)

先ほど申請しました。--Taisyo 2011年5月28日 (土) 01:26 (UTC)

コメント 参考までに申し上げておくと、編集フィルター#12（変更履歴・一致記録）を含む他の対LTAフィルターでは、そのような細かい制御によってその機能を実現していますので、技術的には可能です。方法としてはおっしゃるような形になるでしょう。ただし問題としては、WP:EF/R#フィルターを提案する前ににあるように、編集フィルターはすべての操作に対して確認がかかるので、結果的に動作が若干重くなるということで、特定のページに対してのみの導入はあまり推奨されません。RFAの投票を編集フィルターで実現しようという提案もありましたが、不作成となっています。また、作成することになっても、そのコードの軽量化が求められます。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント 結論は青子守歌さんに言われましたので。常駐型としては負荷を考慮する必要があり不向きであると思います。ただ、これとは別に短期的、または暫定的に編集フィルターを活用した疑似編集制限を、使用する場面もあるかもしれないので、研究する価値は有ると思います。--Taisyo 2011年5月28日 (土) 11:23 (UTC)

コメント 作るわけではないですが、もし作るとしたら（将来的に技術的アプローチの参考にする為）。1つめは「ある特定のテンプレートを張ってある記事は、最低投稿回数及び新規ユーザーは編集できなくする」フィルターを作成。それだけでは、テンプレートを一般ユーザーも自由に貼り付け出来、管理者権限のない人も管理者同様の対応が出来てしまうので、2つめのフィルター「有る特定のテンプレートの貼り付け及び削除は管理者権限を持った人のみが出来る（差分参照）」かと思います。もしかしたら、もう少し賢い方法で実現するのかもしれないですが。--Taisyo 2011年5月29日 (日) 12:04 (UTC) , 一部修正--Taisyo 2011年5月29日 (日) 12:12 (UTC)

コメント フィルターの問題点を。期間固定式は実現しやすいと思いますが、可変設定を加えるのは無理なのではと思っています。単純に厳しくする形で実現するのかなと思います。--Taisyo 2011年6月1日 (水) 13:04 (UTC)

自動承認

（戻します） en:Wikipedia:Semi-protectionを確認してみたのですが、英語版では「登録から4日かつ10編集以下」と日本語版と比較して、拡張された仕様が採用されているようです。いくつか考えられるのは、現行の半保護を英語版並みに拡張する（導入に関しては一番楽だが、一律厳しくなるのは問題）。英語版の半保護を「半保護2（仮称）」の形で、現行半保護と平行して導入する（セレクタの追加は必要）。最初の提案通り、完全可変設定を目指す（技術的には大変だが、きめ細かい対応が出来る）。いくつかの選択肢がありそうです。脈無しの話ではなさそうです。--Taisyo 2011年5月28日 (土) 01:26 (UTC)

コメント これは半保護の設定をいじっているのではなく、自動承認の要件自体が厳しくなっています（en:Wikipedia:Autoconfirmed）。--Jkr2255 (Talk/History) 2011年5月28日 (土) 01:50 (UTC)

コメント 自動承認自体をいじっている。半保護固有の物ではないのですね。自動承認の変更。また別の問題がありそうです。--Taisyo 2011年5月28日 (土) 02:11 (UTC)

コメント 寝かしアカウントにより半保護が無効化される根本の原因は、現在の登録からの経過日数にのみによって自動的に承認していることによるものです。ですから、根本的な解決をするなら、自動承認の基準を厳しくすのが最善であることは確かで、技術的にもこれが一番簡単になります。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント 技術的には楽で効果的である。荒らし対応の意味で、厳しく改正する提案も有ると思います。別途提案して他のユーザーの真意を確かめる必要があると思います。--Taisyo 2011年5月28日 (土) 11:23 (UTC)

コメント LTAによる1アカウントあたりの編集数が10編集を超えている例も見かけますので、10編集以下というのはLTA対策としては甘いのかなと思います。半保護2（仮称）を導入できるのであれば、既に述べましたが初編集から4日（4日でなくてもよいですが。）というのがいいのかなと。--Haifun999 2011年6月2日 (木) 14:57 (UTC)

コメント半保護記事の書き込み禁止設定を初編集から20編集、なおかつ20日以上が良いのでしょうか、半保護記事の書き込み禁止設定は、少し厳しくしないと。半保護設定を変えればかなり編集合戦を防げると思いますが。--Saihare 2011年6月2日 (木) 21:20 (UTC)--Saihare 2011年6月2日 (木) 21:59 (UTC)小修正

コメント 自動承認の条件変更は「寝かしアカウント」に対する直接的な規制になり、妥当な変更目的だと思います。なお、判明している問題点としては、編集回数はあくまでも文章投稿者に対する条件ですので、ファイルをアップロードしたいだけの人にとっては不適当な条件であることです。この点、英語版では管理者が「承認された利用者」というグループを追加/除去できるようにし、この問題に対応しているようです(参考: 利用者グループの権限 (en, ja)、英語版の利用者権限変更記録)。--Frozen-mikan 2011年6月2日 (木) 15:35 (UTC)

コメント Wikipedia‐ノート:進行中の荒らし行為/長期/HATからご案内をいただきました。私もSaihareさんのおっしゃっているような、「登録時からではなく初投稿時を基準とする」取り扱いに賛同いたします。Frozen-mikanさんのおっしゃったファイルのアップロードの件については、現在ファイルのアップロード自体をjawpではなくWikimedia Commonsにアップロードすることを推奨されており、半保護機能についてはjawpのローカルルールとして取り扱えばあまり問題にならないようにも思うのですが、いかがでしょうか。--Bsx 2011年6月5日 (日) 09:28 (UTC)敬称漏れ（失礼しました＞Frozen-mikanさん）--Bsx 2011年6月5日 (日) 21:35 (UTC)

コメント 自動承認の設定を変えれば、実質的に半保護を厳しく出来そうです。現在編集開始日から20日20編集の基準が出ております。これまでと比べたら、それなりに厳しそうですが、まだ厳しくするべきと思う意見も多く出ると思いますし、厳しすぎるとする意見も出そうです。自動承認に段階を設ける事が出来ないのであれば、全て一律対応になると思います。有力案として考慮して良いと思います。--Taisyo 2011年6月5日 (日) 13:56 (UTC)

コメント 自動承認に段階を設けるですが、もし出来るのであれば現行の半保護相当分は英語版と同等の「登録から4日かつ10編集」に、それとは別に提案に出ている「初投稿から20日かつ20編集」と、管理者投票相当の「登録から30日かつ50編集」を設ける事が出来たらと思うのですが、どうでしょうか?--Taisyo 2011年6月7日 (火) 21:22 (UTC)

質問 すみません、自動承認に段階を設けることが出来ると仮定して、実際の自動承認の使い分けはどのようなものを想定しておられるのでしょうか。ある程度一律にしないと混乱を招きそうですが…--Bsx 2011年6月7日 (火) 21:59 (UTC)

コメント質問返し。通常の例はこれまでの半保護での対応で良いと思います。寝かしアカウントなどを使っての編集合戦が発生している記事には、管理者が状況判断して随時切り替える形になると思います。元々の議論の始まりの考え方であるのですが、現行の半保護相当分は、依頼する側・される側の立場から考えて必要に思います。これまでと、重みが極端に変わった場合に、これまでの対応がしづらくなると思います。英語版などの様に「4日かつ10編集」だったら、そう大きく変わる物では無いと思いますが、スペイン語版の様に「4日かつ50編集」やさらに強化版でしたら、一荒らしの為に厳しくしすぎだと受け取られるかもしれないです。後の議論で、段階は難しいとの意見も有りますが、ある事を考えましたので、それなら多分出来るのでは無かろうかと思います。--Taisyo 2011年6月8日 (水) 10:44 (UTC)

コメント 「自動承認に段階を設けるとしたら」の話で盛り上がっているところ恐縮ですが、今のところ、ウィキメディアのウィキで半保護の段階を設けるために自動承認に段階を設けるのは技術的に困難です。 ちょっと話が混乱するかもしれませんが、半保護の仕組みと自動承認について説明します。まず、自動承認された利用者(英語: autoconfirmed user)は、「自動承認された利用者」(autoconfirmed)グループに属しており、現時点でjawpでは以下の8コの権限を与えられています。

• 「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha)
• 「ファイルをアップロード」(upload)
• 「ブックを共有ページとして保存」(collectionsaveascommunitypage)
• 「ブックを利用者ページとして保存」(collectionsaveasuserpage)
• 「ページを移動」(move)
• 「他の利用者の編集を巡回済みにする」(patrol)
• 「IPベースの速度制限を受けない」(autoconfirmed)
• 「既存のファイルに上書き」(reupload)

そのうち、半保護ページを可能にしているのは「IPベースの速度制限を受けない」(autoconfirmed)という権限です。半保護に限らずMediaWiki一般的に言えば、「ある作業が可能かどうか」を実質的に設定するのは権限グループではなく、権限そのものとなっています。ですから、半保護に段階を増やすためには、権限そのものを増やさなければなりません（例えば、autoconfirmed2とかautoconfirmed3とか）。そして権限そのものを増やすためには、コード自体を変更せねばならず、つまり#開発を依頼するとほぼ同じことを意味します。ですから、「半保護を可変にする」ということ自体が事実上困難です。 しかし一方で、MediaWikiには「自動昇格」(英語: autopromote)という仕組みがあり、「ある一定の条件を越えたら自動的に手に入れられる権限グループ」を設定することができます（c.f. mw:Manual:$wgAutopromote)。「条件」には編集回数や登録からの時間、さらには初編集からの時間や、技術的にはIPアドレス（範囲）の指定も可能です。自動昇格自体は他のウィキでも既に利用されており、詳しくは設定ファイルのwmgAutopromoteExtraGroups変数の設定を見てもらえればと思いますが、フランス語版ウィキペディアで「自動巡回者」(autopatrolled)や、ロシア語版ウィキペディアで「アップロード権限保持者」(uploader)などが設定されています。実のところ、「IPベースの速度制限を受けない」(autoconfirmed)もこの自動昇格グループの1つに過ぎません - もちろん歴史的には先に実装されていますが。つまり、

1. 新しい権限グループを作り
2. 現在の「自動承認された利用者」(autoconfirmed)に割り当てられている8コの権限を分離して、新設した権限グループに割り当て
3. 新設したグループへの自動昇格を設定する

ことは可能です。新しい権限グループと割り当ては、全部バラバラにして、「キャプチャをスキップできるグループ」「アップロード出来るグループ」「移動出来るグループ」「パトロールできるグループ」「巡回できるグループ」「半保護を編集できるグループ」もできますし、（従来の意味での）「自動承認利用者」「半保護編集者」「アップロード担当者」「移動および巡回担当者」みたいにすることもできます。ですから、「（他の条件はそのままで）半保護だけの編集条件だけを厳しくしたい」という場合にはこれが使用できます。これはbugzillaで言えばさらっとやってくれるでしょう。

個人的には、アップロードも移動も半保護も全部一緒に厳しくしてしまえばいいんじゃないかと思いますが（そもそもアップロードはコモンズに行けばいいわけですし）、みなさんが「いやそれはちょっと・・・」というなら、こういう選択肢もとりうることができます。--青子守歌（会話/履歴） 2011年6月8日 (水) 03:50 (UTC)

コメント利用者の権限グループと、存在する権限に依存する件。了解しました。「IPベースの速度制限を受けない」(autoconfirmed)の可変設定は難しい件も了解しました。もし、「IPベースの速度制限を受けない」(autoconfirmed)の日数及び編集回数のみを変更した「autoconfirmed2」権限を作るのも色んな絡みで難しいのですよね?

つまりは、権限グループの作成は簡単である。既にある権限を使うのは楽であると読み取って考えてみました。先に出てきた議論で、en:Wikipedia:Pending changesがあります。その中の「Pending-changes level 2 with Semi-protection」と「Reviewer」を活用し、現在「登録から4日」の「自動承認された利用者」の上位利用者グループ「自動承認された利用者2（仮）」を作成して、「自動承認された利用者」は「Pending-changes level 2 with Semi-protection」のページ編集に関しては承認待ちに、「自動承認された利用者2（仮）」に関しては「Reviewer」権限を与えることで、擬似的に実現出来るのでは無かろうかと考えました。「自動承認された利用者2（仮）」については、「初回編集から20日かつ20編集」や「初回編集から30日かつ50編集」などでやれば思います。現在の「自動承認された利用者」を、一定水準を超えたら「自動承認された利用者2（仮）」にする形になります。、en:Wikipedia:Pending changesの導入はしにくくなるかもしれないですが、それが問題かもしれないです。--Taisyo 2011年6月8日 (水) 10:44 (UTC)

「査読者」(reviewer)グループが何を表しているのかよく分かりませんでしたが、単に「自身の編集を自動的に「確認済み」にする」(autoreview)というだけなら、「査読者」(reviewer)ではなく「信頼された利用者」(trusted)や「自動査読者」(autoreviewer)の方が近そうです。で、PendingChangesあるいはFlaggedRevsを導入できたとして、「信頼された利用者」(trusted)や「自動査読者」(autoreviewer)などの「自身の編集を自動的に「確認済み」にする」(autoreview)をもつグループに自動昇格を適用するのはあまり賛成できません。自動昇格で自動的に査読済にできてしまうようになると、なんのための荒らし対策か分からなくなるように思います。それよりはむしろ簡単な投票のように「申請→反対なしなら付与できる」ぐらいが良いと考えています。あるいは、自動昇格にする場合でもかなり条件を厳しく、かつ問題があればすぐに外せるぐらいの感じでないと、と思います。と、ここまで書いていてちょっと目的が何か分からなくなってきました。荒らしのような不適切な投稿を「させない」ならPCなどなくとも半保護ページの編集条件を上げ（半保護編集者のような権限を作って自動昇格にすることも含む）ればよいだけでしょう。ではなくて、包括的に「慣れていない編集者（LTAなど含む）の編集を表に出したくない」というのなら、PCやFRの出番になります。冒頭で述べられいる理由（内容）やページ名と少し話が剥離してきているようにも思いますし、改めて「こういうことをしたい」という目的をはっきりさせたうえで、別ページに動かしたほうが良いのかもしれません。--青子守歌（会話/履歴） 2011年6月8日 (水) 13:57 (UTC)

コメント 指摘の通り、議論の本題に据えた議論とは議論の初めからずれていた様な気がしております。そもそもが、「技術論抜きでこんな物は出来ないのかな」がスタートでした。最初の議論で出した「半保護の可変」にあえてこだわりたかった意味は、一部の荒らしユーザーが寝かしアカウントで荒らしを行う現実がある。その上で、半保護の現行水準「登録から4日」を単純に引き上げるのは、当初の半保護の「速報的な編集の予防」を位置づけが変わるのは問題でないのか。また、閾値を固定の形で上げる事で、その閾値に合わせる形で荒らしユーザーが対応する可能性がある。その中で、閾値を可変にする事で柔軟な対応が出来るのではないかと考えたからです。

しかし、技術の問題はありますので、技術対応が楽か困難か。技術的に楽でも、利用者の同意が得られやすいか。一個人的に権限を把握していないのもありますので、イメージする物を実現するのに活用出来る権限が存在するのか。その点に、議論の軸を移さないといけないのかなと考えています。それが、当初のテーマの剥離に拍車を掛けるのだと思います。

現在考えているのは半保護と保護の間に、もう一段階中間レベルの「保護」を作る事で、それを荒らし対応用に使えないだろうかです。権限グループの作成は楽な様なので、それとは別に、活用出来る権限は無いだろうか。日本語版に無い利用者グループ用の権限グループなどを活用してです。半保護と保護に関しては、現行レベルを基本的には維持。「新保護」は、既に出ているとおり「20日20記事」や「30日50編集」など、支持が一番多い閾値になると思います。

どの様な形で現実化をしていくかが決まった時点で、半保護の変更で無くなった場合は、名前も見直さないといけないのかなと思います。

「欲しい仕様」と「実際に使える技術」。仕様を実現する為に、どの様な技術が活用出来るかになっていくのかなと思います。

en:Wikipedia:Pending changesを見て気がついたのは、現行の日本語版で採用されている「未保護」「半保護」「全保護」以外の段階が、何だかの形で作る事が出来るのではないかと思っています。

青子守歌さんの不満「私自身の権限の活用方法の悪さ」については、色んな権限を教えて頂きたいと思います。--Taisyo 2011年6月8日 (水) 15:28 (UTC)

前回の話は、en:Wikipedia:Pending changesを実現する為に、新たに作成された「権限」が有ると思いますので、それを日本語版独自の「権限グループ」を作成、自動承認を活用して出来ないだろうかの問いです（もし、全く別の技術で実現しているのであれば無理でありますが）。半保護の可変が難しそうなので、固定でもう一段階造る路線へ変えております。--Taisyo 2011年6月8日 (水) 16:28 (UTC)

「荒らし対策」が目的ではっきりしているならば、それはご承知のとおり半保護の可変（段階化）によらずとも達成できるものです。単純に半保護の編集レベルを引き上げるだけでも十分な効果でしょう。また、半保護と全保護の中間の保護レベルを作成することはかなり困難だということは先に申し上げた通りです。中間保護を仮に設定したとして、それをどう活用すれば荒らし対策になるのか、そこをもう一度きちんと詰める必要があるのではないでしょうか。それによって「それならこの機能が使える」と具体的な代案などの意見が出やすくなるはずです。一方、PendingChangesについては、「編集できないようにする」ではなく「編集を見えなくする」機能ですから、保護とはまた別の話になります。ゆえに、「半保護の可変」の範疇の議論にはあたらないですし、そのような認識で議論を進めないほうがよいです（ところで、以前お伝えしたとおりPCは現在も開発中の機能であり、enwpのように開発者との連絡が活発なコミュニティーならまだしも、現状のjawpに導入するのはコミュニティーにとっても開発者にとってもあまり良い結果をもたらなさそうだと思いましたので、「FlaggedRevsを」と申し上げたのですが、それでもなお、PCにこだわるのはなにかあるのでしょうか？）。--青子守歌（会話/履歴） 2011年6月8日 (水) 17:36 (UTC)

コメント まず、PendingChangesにこだわる必要はないと思います。先の議論で出てきたので興味があり、活用をと考えましたが、経緯までは分かってないので、開発途中の物であるので扱いにくい件までは考えてなかったです。FlaggedRevsについて、どの様な権限が使われているのか調べてみたいと思います。中間保護の必要性。単純に半保護を厳しくするだけではいけないのか、調べてみる必要はあると思います。もし、FlaggedRevsについて、日本語で読みやすいのがあれば教えて頂ければ幸いです。それで、中間保護みたいな物が実現出来るのか考えてみたいです。--Taisyo 2011年6月8日 (水) 22:09 (UTC)

FRについての日本語での解説は残念ながら私の知る限りではいいものはありません。一般的に言って、MediaWikiを含むウィキメディアグローバルでの何らかの情報を得ようとする場合は英語が主言語になってしまいますので、こればっかりは「頑張って英語を身につけてください」としか言いようがありません。時間があればmw:Extension:FlaggedRevsを翻訳してみようかとは思いますが、あてにはしないでください。いずれにしても「荒らし対策」のために、「こうしてこうしてこうできればこう改善できるのでこういう機能がほしい」のように具体的に考えをまとめて改めて書かれるのが一番な気がします。先にも申し上げたとおり、現状では私から提案できる内容は出尽くしているようです。--青子守歌（会話/履歴） 2011年6月9日 (木) 08:09 (UTC)

コメント mw:Extension:FlaggedRevs/jaで部分的に翻訳されておりますが、完全ではないです。基本的には「review（査読）」・「validate（有効化）」がベースなのかなと思います。恐らく、指定したページの差分の有効化を一時的に保留にし、 それを取り込む事で、「半保護より問題があるページに関しては、査読を有効化するまでは表示されない」。「review（査読）」・「validate（有効化）」を現在の「自動承認された利用者」に組み込んでいく事で、半保護とは別の形で対応出来る可能性はあるのかなと思いました。また、「PendingChanges」の基本権限の1つなのかなと思いました。

とは書きましたが、現在の半保護について、どのレベルまで厳しくする事に了解が得られるか確認してみる必要があると思います。もしかしたら、アカウント寝かし荒らしに対応出来るまで半保護を引き上げる事に理解が得られるのかもしれないです。新しい節を起こして、確認してみたいと思います。半保護の閾値の引き上げが技術的には一番楽なのは事実のようです。--Taisyo 2011年6月9日 (木) 11:01 (UTC)

Pending changes

コメント いわゆる寝かしアカウント対策であればen:Wikipedia:Pending changesの導入を検討した方がよいのではないでしょうか？--Web comic 2011年5月28日 (土) 01:56 (UTC)

コメント 機械翻訳しながら見ています。かなり細かいシステムですね。評論家（仮）みたいなユーザーも作る必要があるようです。時差反映とか。導入には時間がかかりそうですね。--Taisyo 2011年5月28日 (土) 02:11 (UTC)

コメント 英語版でどの様な経緯で導入されたかは不明ですが。日本語版では、現行システムとの違いが多すぎるかもしれないです。中継ぎ的なシステムも必要かもしれないです。自動承認の変更が先かもしれないです。英語版にも色んな経緯が有るのでしょうから。その経緯を飛ばして導入するのも、混乱の原因になるかもしれないです。--Taisyo 2011年5月28日 (土) 02:18 (UTC)

コメント LTAやテスト投稿などを含む不適切な投稿の公開を防ぐという意味なら、このPCもしくはmw:Extension:Approved Revision、そして一番実績のあるmw:Extension:Flagged Revsなどが有効なのは確かでしょう。PCはまだ開発中の機能で主にウィキペディア英語版でのみ使用されていることを考えれば、導入するならFlagged Revsになるでしょうね。ただし以前に導入が検討されたときには査読（＝公開されても問題ないと判断する≠内容の正確性を保証する）人が追いつくかどうかという問題で、そのまま立ち消えになった覚えがあります。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント 導入するかどうか別として、研究する意味でルールを日本語翻訳するのは良いと思います。実績とかも確認してみたいです。ただ、複雑なルールを開発した所で、ユーザーがついて行けなければ意味が無いのは、わたしもそう思います。--Taisyo 2011年5月28日 (土) 11:23 (UTC)

ユーザーアカウント登録の制限

わたしも、代案と言うべきか合わせ技として使えば効果的だと思う案を出します。現時点で、5アカウントまで登録できるようです（1日に付だったはずです）。それを、2アカウント目以降はメールアドレス登録を義務化するなど、2アカウント目以降は厳しい条件で無いと登録でき無い様にしてはと思いますが、どうでしょうか。--Taisyo 2011年6月1日 (水) 12:56 (UTC)

開発を依頼する

技術的に考えたとき、「半保護に段階を設けたい」という機能を実現する最善の方法は、そのような機能を開発者たちに依頼することです。jawpコミュニティーがそれを望んでいるということをまとめて、それを伝えれば、彼らは動いてくれるはずです。負荷的な問題があるかもしれませんが、少なくともソースコード上ではそれを実現するよう改変することは難しくないように見受けられました。ローカルだけで決められる話ではないので少し難しいように感じてしまうかもしれませんが、このような機能はこれからも必要性が上がるでしょうし、ほんとうに必要なMediaWikiに機能として組み込んでもらうべきかなと思います。--青子守歌（会話/履歴） 2011年5月28日 (土) 07:33 (UTC)

コメント 採用を検討して欲しいのであれば、賛否だけは頂きたい所であります。思ったほど、集まっていないので、議論を行っている事をさらに知らしめるべきか悩んでいる所です。--Taisyo 2011年6月1日 (水) 12:56 (UTC)

えっとちょっと気がついたんですが半保護を可変にするのではなく、半保護と保護以外にもうひとつの保護設定(lowprotectみたいな設定）を設けてそちらの方を現在の自動承認グループに設定する。新たな自動承認グループに現在の「IPベースの速度制限を受けない」(autoconfirmed)を設定すると言った方法なら開発じゃなく設定ファイルの変更で可能なような気がします。SYSOPが保護設定する時に3つの中から設定ランクを選択する事になり少し煩雑になりますが…。新たな自動承認設定を現在の自動承認よりハードルを高くすることにより、見掛け上半保護を可変にする事と同等の効果が期待できませんか?（上記の設定提案はグローバル権限の絡みがあるので「IPベースの速度制限を受けない」(autoconfirmed)を中間的な保護設定にしてます。)--Vigorous action （Ｔａｌｋ/History） 2011年6月23日 (木) 14:35 (UTC)

コメント Vigorous actionさんの案では(lowprotect)のような設定を設ければ比較的簡単な可能性がある。「lowprotect」を現行半保護レベルの物にして、autoconfirmedを上級移行させてしまうのですね。逆にautoconfirmedをそのままに、「highprotect」を設定して、新しい自動承認に割り当てる方法も有るという事ですね。両方とも出来るのか気になります。--Taisyo 2011年6月23日 (木) 14:53 (UTC)

現行の保護設定をそのままにして、「highprotect」を設定する方法も技術上可能です(もっと言えば技術的にはprotectの段階を10でも20でも設定できます）。ただ、グローバル権限との絡みから好ましくないと考えます。もしjawpでhighprotectを設定するとなるとGRとかグローバルボットなどに対してhighprotectを付与しないといけないように考えます。stewardがcross-wiki vandalismなどで介入した場合にhiprptectで編集できないなどが無いようにしなければならないので、グローバルフラグの設定状況をjawpのためだけに設定し直す、又はローカルでグローバルフラグ付与の都度手動で権限付与を行わなければならない事になると考えます。アカウント作成後4日だけ待てなら待ってくれる（多分グローバルフラグ取る前にjawpにアカウント作成はされている）ため弊害はない(or低い)でしょうが、hiprotectを作成した場合かなり影響が出る事が考えられます。実際の運用上名前は事なりますが、「IPベースの速度制限を受けない」(autoconfirmed)をHiprotectの扱いにするだけですので、その後の作業効率が相当変わる事などからautoconfirmedより上に「highprotect」を設定する事は消極的です。--Vigorous action （Ｔａｌｋ/History） 2011年6月23日 (木) 16:34 (UTC)

わたしの考えるグループ権限について内容を示しておきます。

自動承認された利用者1(現行の自動承認された利用者に相当）

• 「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha)
• 「ファイルをアップロード」(upload)
• 「ブックを共有ページとして保存」(collectionsaveascommunitypage)
• 「ブックを利用者ページとして保存」(collectionsaveasuserpage)
• 「ページを移動」(move)
• 「他の利用者の編集を巡回済みにする」(patrol)
• lowprotect(現行は「IPベースの速度制限を受けない」(autoconfirmed)）
• 「既存のファイルに上書き」(reupload)

自動承認された利用者2(新しく作成するグループ）

• 「IPベースの速度制限を受けない」(autoconfirmed)

現行の自動承認の昇格条件を引き上げるのであれば

手動で付与するグループ（グローバル権限保持者など対象）

承認された利用者

• 「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha)
• 「ファイルをアップロード」(upload)
• 「ブックを共有ページとして保存」(collectionsaveascommunitypage)
• 「ブックを利用者ページとして保存」(collectionsaveasuserpage)
• 「ページを移動」(move)
• 「他の利用者の編集を巡回済みにする」(patrol)
• lowprotect
• 「IPベースの速度制限を受けない」(autoconfirmed)
• 「既存のファイルに上書き」(reupload)

などがあったほうがいいと思います。

なお「IPベースの速度制限を受けない」(autoconfirmed)より上の保護グループを新規作成する場合はローカル議論ではなくMETAでも提案&議論の必要があるとわたしは考えます。--Vigorous action （Ｔａｌｋ/History） 2011年6月24日 (金) 14:11 (UTC)

コメント なるほど・・・ローカル権限の重みですね。てっきり、metaの人がjaの臨時管理者になる時に日本語版の管理者の権限になると思ったら、meta並みの権限になるようですね。就任自体はローカルで行わないといけないでしょうから、色々弊害も有るのでしょう。もっとも、lowprotectも初期設定時点で手動承認できるようにも出来るでしょうから、権限違いのトラブルを最小限に出来るでしょうけど、ゼロではないのでしょう。思い違いなら御免なさい。--Taisyo 2011年6月24日 (金) 14:03 (UTC)

• グローバルフラグは、色々なプロジェクトでそれぞれ権限付与申請だとかが与奪操作が面倒なので全部のwikiで事前に権限付与されてたりします。例えば、いま現に荒らしが行われている時にスチュワードが自分に対してjawpの権限付与を行わうような手間をかけて対処が遅れるであるとかでは困りますから、スチュワードと言うグローバル権限でこの様な]業務ができることになっています。もしこの権限グループに入っていない権限があれば、その時はローカルwikiのアカウントに対してその権限を付与する形になります。（手動で与奪できるようにしてあれば権限グループの追加は、METAでもローカルでもできます。）--Vigorous action （Ｔａｌｋ/History） 2011年6月26日 (日) 03:18 (UTC)

コメント 追加コメントに対する補足。大体は、私のイメージしていたのと同じです。autoconfirmedより上級権限を作った場合にメタの承認も取った方が良い件も納得しております。今の案の中でautoconfirmedの最大強化案は2ヶ月100編集になっております。個人的にはやり過ぎかなと思いつつも、票を集めるのではと思っております。autoconfirmedで現在の時点で一番厳しいのは、スペイン語版の4日50編集なので格差が大きい気もしております。autoconfirmedの強化は青天井で解釈しても大丈夫なのでしょうか。そちらも何か気になります。内容は余り気にしないで、権限のみ気にするのであれば楽ですけど。--Taisyo 2011年6月24日 (金) 14:25 (UTC)

• かなり高い数字ですね。その時は手動でautoconfirmed権限を付与できるシステムも入れておいてwmfプロジェクトでなんらかの信任を受けているとか、SULで結合されたアカウントで一定以上の実績がある人に権限を付与する形をとれば大きな問題はないのではと個人的には思います。あと御懸念の権限の取り消しですが自動承認を取り消すのではなく権限の停止させる権限グループ作成して、そのグループを付与する形で自動承認を取り消しできます。グローバル権限グループの絡みでいえばスタッフの一覧にあるように、現状jawpにアカウントを作成されていない方もおられます。スタッフがローカルwikiに来る事はほとんどないのでしょうが、念の為ほかのグローバルグループでautoconfirmedを持つグループに属する人でjawpにアカウントを作成していない人(ざっと確認したところ、30人弱）には連絡してアカウントの作成だけでもお願いしておく方がいいと思います（lowprotectの関係があるので）。--Vigorous action （Ｔａｌｋ/History） 2011年6月26日 (日) 03:18 (UTC)

• そうなのです。かなり高い値も出ております。実際に管理権限の運用者であれば、値の重みはある程度は理解しておりますが、それを一般利用者に分かってもらうのは難しいのかなと思います。比較的小さい値で、効果的な値。それを理論詰めて説明できれば良いのですが。個人的には2週間50編集程度が上限値程度に考えたりしています。それと事前に、meta関係者にjaアカウントの作成が必要なのも納得です。元々割り当てられた権限で対応している。英語版などはかなり独自の権限体制になっているでしょうから、それなりにmetaのほうでも対応しているのだと推測します。もっとも英語版利用者が圧倒的でしょうから、大きな問題にはなりにくいのかもしれないです。--Taisyo 2011年6月26日 (日) 06:56 (UTC)

現行の半保護について

現行の半保護について

技術的に詳しい方は、読み飛ばしても良いと思います。改めて、私を含めた初心者の為におさらいします。

現在の半保護について、登録から4日で編集できるようになっております。それを実現する為の方法として、ユーザー登録から4日で自動的に「自動承認された利用者」(autoconfirmed)「自動承認された利用者」になり、その中の権限に「IPベースの速度制限を受けない」(autoconfirmed)があり、その事で実現しております。「自動承認された利用者」から「IPベースの速度制限を受けない」(autoconfirmed)を分離した上で、別の権限グループを作成する事で、半保護された記事に関しては別の閾値（例として、初回投稿から20日20投稿）が実現します。

また、「自動承認された利用者」自体の閾値を上げる方法も存在しています。実際に英語版などでは「4日かつ10投稿」、スペイン語版では「4日かつ50投稿」に指定しております。

それらの事情より、完全可変の半保護の作成に関しては、きわめて困難。今より基準の厳しい半保護を作成したい場合は、新たな権限作成が恐らく必要になりますので、それなりに難しいと思います。--Taisyo 2011年6月9日 (木) 11:01 (UTC)

先ほど質問がありましたので、「そもそも何故半保護は4日なのか」を書きたいと思います。日本語版から見た事情を。日本語版では2006年1月頃に導入された機能で、英語版などの機能拡張で日本語版でも導入の是非が問われ、賛成多数で機能追加されました。4日は初期設定値です。その値に対して、日本語版では疑問も特に無かったので、現時点まで初期設定値が使われております。他の言語版では、閾値の変更を行った所もあります。--Taisyo 2011年6月11日 (土) 12:31 (UTC)

現行の半保護の改変について

技術的に一番楽なのは、現行の半保護の閾値を変更する事です。反面、現在の半保護の位置づけが「性急な編集の回避」に有ると思いますので、「寝かしアカウント荒らしの対応」目的を入れる事は、同意が得られるのか疑問を持っています。逆に、現在の半保護では「寝かしアカウント荒らしの対応」は困難なのも事実です。

その中で、現行半保護について、何処まで閾値を引き上げて良いのか。その閾値では「寝かしアカウント荒らしの対応」に十分な能力を持つ事が出来るのか。もしも、現行半保護を、「寝かしアカウント荒らしの対応」出来るレベルまで閾値を上げる事に許容されるのであれば、楽と言えば楽です。

これまでに出してもらった値が「現行半保護が存続すると仮定して、別の閾値を」でしたので、今回は「現行半保護の閾値を何処まで上げて良いのか」確認してみたいと思います。--Taisyo 2011年6月9日 (木) 11:01 (UTC)

コメント個人的には、スペイン語版並の「4日かつ50編集」に上げても良いかなと思っています。恐らく、寝かしアカウント対策に関して「50編集」が有効に反応すると思います。--Taisyo 2011年6月9日 (木) 11:01 (UTC)

コメントそれいいアイデアですね。今の状態だと5日位まで書き込まないで、いきなり荒らしに取りかかる事例がおきてますから。昨日も寝かしアカウント3発遭遇しているので早期導入を望みます--Saihare 2011年6月9日 (木) 12:13 (UTC)

コメント 先にも述べたとおり、半保護編集が可能にするのを現行より厳しくして良いと思います。「登録から7日経過、かつ50編集」ぐらいでもいい感じですが、たぶん「荒らし対策」に登録日数はあまり効果的でないですから、日数については現行以上であれば特に意見はありません。そろそろ意見を広く募るためにお知らせなど各所で告知が必要な時期かもしれませんね。--青子守歌（会話/履歴） 2011年6月9日 (木) 12:55 (UTC)

コメント 半信半疑の部分が正直有りますけど、半保護の閾値を上げられる余地がどれだけあるのか確かに気になっております。井戸端もそれなりに目立ちますけど、お知らせとかも考えないといけないですね。それと、もし「半保護記事編集者（仮）」の権限グループを作成するとして、BOT等の場合に、半保護の閾値に引っかかる例が多いかもしれないですから、本来「半保護記事編集者（仮）」は自動付与を考えておりますが、BOT権限に組み込んでおく。または、「半保護記事編集者（仮）」を手動で付与出来る様にもしておく。もし、自動付与と手動付与の両設定を可能にするのが無理なのであれば、付与のみを変えた「半保護記事編集者（自動）」・「半保護記事編集者（手動）」とかも考えられるかもしれないです。閾値を上げる事の弊害であり得るのかなと思いましたので、触れてみました。--Taisyo 2011年6月9日 (木) 13:14 (UTC)

新規参入bot（＝自動昇格の権限を満たしていないbot）については、私は特に対応は必要ない（半保護の記事をbotが編集する必要性もないですし）と思います。むしろ暴走botを止めれない可能性があるので、入れないほうが良いのではと思います。手動付与については、ちょっと記憶が曖昧だったのでIRCで確認してきたところ、「たぶん同じグループで大丈夫」とのことでした。必要なら手動付与を可能にする設定は簡単にできるでしょうが、その必要性はあるのかなぁという気はします。まぁ「あって困るものではない」と考えればsysopあたりにつけておいてもいいような気はしますが・・・。--青子守歌（会話/履歴） 2011年6月9日 (木) 14:37 (UTC)

コメント 半保護編集権について。管理者割り当てに新規BOTにはデフォでは割り当てない。特に問題ないと思います。手動割り当ても、厳しくなるので「用意しておいても良いのでは」です。技術的に難しくはないはずですので。--Taisyo 2011年6月9日 (木) 22:00 (UTC)

コメント 先ほどWikipedia:お知らせに書き込んできました。普通のお知らせでは、ほぼ全てやった形です。あとは、管理者権限などを用いて、MediaWiki:Sitenoticeなどへのお知らせ文を書くかどうかですが、個人的には判断しきれません。--Taisyo 2011年6月10日 (金) 13:44 (UTC)

コメント遅まきながら・・・。上記でBotを除外されているようですが、現状ではBotフラグには「IPベースの速度制限を受けない」(autoconfirmed)が付与されています。またBotにはGlobal botなどがあったり、他言語版の利用者が運用するBotが日本語版で活動しているなどの場合があったりします。Botが例えば誤動作した場合それらを正常の状態に戻すのは原則Botオペレーターの責任です。この様な場合Botオペレーターが日本語版ではBotアカウント以外での編集が少なくそれらを差し戻せないなどの状況も発生する可能性があります。したがって、他言語版がhomewikiになっている利用者であってGlobal botや日本語版におけるBotフラグをもつBotオペレーターで日本語版における編集回数が自動承認を満たしていない場合に手動で権限を与える事が可能であるようにするべきであると考えます。（そもそもBotフラグを付与する場合に、荒らしなどの問題投稿をしている人の運用するBotにフラグを付与する事はありませんから。）--Vigorous action （Ｔａｌｋ/History） 2011年6月11日 (土) 03:33 (UTC)

コメント 失礼しました。今確認したらBOTアカウントには元々半保護編集権限は割り当てられていました。もっとも、不要とする意見が多数であれば再考するべきかもしれないですが、あくまでもBOTフラグは信用置ける利用者が取得する前提ですので、現状のままで良いと思います。--Taisyo 2011年6月11日 (土) 12:31 (UTC)

コメント他言語版がhomewikiになっている利用者であってGlobal botや日本語版におけるBotフラグをもつBotオペレーターで日本語版における編集回数が自動承認を満たしていない場合に手動で権限を与える事が可能であるようにするべきであると考えます。の部分はいかがでしょうか？--Vigorous action （Ｔａｌｋ/History） 2011年6月15日 (水) 11:53 (UTC)

コメント ところで、なぜ4日間は半保護の対象となるのでしょうか。--プログラム（会話 | 投稿記録） 2011年6月11日 (土) 11:25 (UTC)

コメント #現行の半保護についてに追記しました。日本語版から見た事情の形で書きました。--Taisyo 2011年6月11日 (土) 12:31 (UTC)

コメント この様な利用者を見てまして、50編集でも大丈夫なのか不安になっております。早期に見つけて対応出来るのであれば問題ないのですが。青子守歌さんの7日50編集も悪くないと思いますが、それよりも編集数の値を再考する必要があるかもしれないです。他の方が色んな所で、議論していることをお知らせして頂いてますので有りがたく思います。反面、まだ意見とか少ないので、先に躊躇したMediaWiki:Sitenoticeなどへも置いた方が良いかもしれないです。--Taisyo 2011年6月14日 (火) 10:29 (UTC)

コメント 初編集から3日かつ100編集にするのはどうでしょうか。--プログラム（会話 | 投稿記録） 2011年6月15日 (水) 09:03 (UTC)

コメント 3日間で100編集。ある意味極端な値ですが。短期間で100編集するとしたら、カテゴリー貼り付けなど、かなり数が限られております。合理性は別にしても、興味深い考えです。100編集なら2週間程度でも良いかもしれないです。--Taisyo 2011年6月15日 (水) 12:09 (UTC)

コメント方法論での話になりますが自動承認では「IPベースの速度制限を受けない」(autoconfirmed)を与えないという選択肢もあります。新たに半保護編集者の様なものを利用者グループとして作成しそれは、ボット権限申請のように権限付与申請を利用者からの申請を元に審査を行い、管理者等が権限を付与する形での運用も可能であると思います。この場合同等以上の審査を行った上で権限を付与されるBot・管理者・編集フィルター編集者・現在議論中の削除者や巻き戻し者などには、そちらの方にその権限を付与する形をとっておく必要もあるでしょう。そうすることによりjawpで申請を行ったもの以外ではGlobal bot・Global_rollback・Stewardsなどの一部のグローバル権限を有する利用者のみが半保護ページを編集する事が出来るようになります。ただ、半保護と保護の差がほとんどなくなってしまうという弊害もあると思います。--Vigorous action （Ｔａｌｋ/History） 2011年6月15日 (水) 11:53 (UTC)

コメント 半保護の立ち位置を変える考え方ですね。準全保護的にしてしまう。個人的には、今の半保護の立ち位置は残したい気持ちが強いですけど。方法論的には十分有りです。私も考えたのは、個人的にこんな運用は反対なのですが、ブロック依頼に出されたユーザーへの問題解消手段として、半保護記事への編集権限を取り除く方法もあり得ると思います。自動承認は生かしたままで。元々、自動権限がないユーザーへの割り当ても出来るのですから、逆も出来るでしょう。運用論的な考えですので、考えついていても。導入要望があれば考慮ですが。--Taisyo 2011年6月15日 (水) 12:09 (UTC)

コメント 改めて考え直したのですが、半保護権限の手動剥奪は事実上無理な様な気がしております。処理の上では、半保護権限の剥奪は出来るのですが、剥奪直後に自動承認が働き事実上剥奪にならないのでは無かろうかと思います。それを解消する為のプログラムを組むとなると面倒な気もしておりますので、私の解釈違いでなければ無理と思います。--Taisyo 2011年6月16日 (木) 10:14 (UTC)

コメントわたしの意見のぶら下がりなんで一応お答えしておくと、自動承認のはく奪した場合に再度自動承認になるのではという件については、できる又は技術的には可能であると思います（確認はまだとってませんが）。編集フィルターの機能には自動承認をはく奪するという対処があり、自動承認がはく奪された場合そこで自動承認のカウントがリセットがなされ一からやり直す事になるとの事です。--Vigorous action （Ｔａｌｋ/History） 2011年6月16日 (木) 11:36 (UTC)

コメント権限をはく奪するのではなく権限を停止する事は現状のMediawikiの機能で可能である事が確認できました。--Vigorous action （Ｔａｌｋ/History） 2011年6月30日 (木) 04:03 (UTC)

コメントなるほど。可能性として、自動承認の無効化は可能であるのですね。再度カウント開始ですけど、一定の抑止力はあると思います。--Taisyo 2011年6月17日 (金) 12:47 (UTC)

コメント取りあえず確認した方法は、ある権限グループを追加するとリセットではなくその権限グループがはずされるまで特定の権限（機能）が使えなくなります。--Vigorous action （Ｔａｌｋ/History） 2011年7月2日 (土) 09:49 (UTC)

コメント寝かしアカウントが対策としてアカウント作成から何日ではなく初編集から60日でかつ編集実績を100回に変更することを提案いたします。初編集日が無理であれば90日という形にできないでしょうか。--三菱善次郎 2011年6月17日 (金) 05:48 (UTC)

コメント私は半保護制度の導入当時からこのようなことを懸念していたが最近出回っているHAT系による大量荒らし対策としてブロックや従来の半保護では効果が薄いため、大幅な規制強化をすることで、寝かしアカウント対策のためや無害の新規のアカウントを作成された方には大変ご迷惑をかけますが日数だけであれば待つだけで来るものですし編集10回でははっきり言えばページ荒らしや同じ項目を複数回に分けて編集される利用者さんがいらっしゃるため事実上薄いと感じておりますし、一般の期間保護でも１カ月から3カ月と考えれば60日(2か月)でも妥当だと思います。--三菱善次郎 2011年6月17日 (金) 12:29 (UTC)

コメント通りすがり的な荒らしユーザーを例外で考えるか、長期荒らしユーザーを例外で考えるかで変わると思います。投稿開始からカウントも先の話では出来そうな感じでした。典型的な長期荒らしユーザー対応シフトですね。個人的には此処まで長くなくてもの気持ちがあります。長期荒らしユーザーは多数のアカウントを作るわけですので。少し重たい程度でもボティブロー的に効いてくるはずです。先の4日50編集でも。典型的な一発アッパー型ですね。個人的には重すぎる気もしております（先の意見参照）。もし支持者が多ければ採用だと思いますが。半保護の問題も、最初から気がついていましたし、その問題が問題になる例はレアケースだろうと考えてきました（今でも基本的に、一ユーザーの問題と思っています。）。--Taisyo 2011年6月17日 (金) 12:47 (UTC)

コメント 初編集から60日かつ標準名前空間の編集100回以上にするのはどうでしょうか。--プログラム（会話 | 投稿記録） 2011年6月18日 (土) 13:41 (UTC)

コメント 半保護はノートも対象に行われることもありますから、あまり日数を長くしすぎると真面目な新規ユーザーが議論に参加しづらくなりますから1ヶ月2ヶ月というのは賛成しかねます。あと、荒らし対策でいえば週単位だといつから編集できるかというのが分かりやすいので、そうではない方が良いのではないかと思います。私は、10日ないしは15日かつ50編集ぐらいで良いのではないかと思います。--UE-PON2600 2011年6月29日 (水) 17:03 (UTC)

コメント Taisyoさんが上記で指摘されていた新規記事の粗製濫造をする利用者ですが、こうした利用者に対応するには英語版のように新規記事作成に対する半保護措置をしない限り、現状では阻止する手段は事実上存在しません。これに関しては別途検討する必要があると考えます。--Web comic 2011年6月22日 (水) 15:14 (UTC)

コメント 全手動対応になると思います。この様な投稿をしたら余りにも目立ちすぎるので、対処は出来るだろうと思っています。一応は考えてはいますけど。--Taisyo 2011年6月23日 (木) 12:25 (UTC)

コメント これまでの値をまとめてみました。結構、期間長めかつ編集数が多い案が多いので、最初の心配は考えすぎだったのかもしれないです。--Taisyo 2011年6月18日 (土) 13:53 (UTC)

コメント 荒らし対策のみに注目した条件の設定には賛成できません。自動承認の条件は登録間もない利用者であるかどうかを大まかに判別するものであって、荒らし行為を根絶するものではないはずです。荒らし対策よりは大勢の利用者の利便を優先したいです。それを踏まえると、多めにとっても登録または初投稿から7日、編集回数は10回までが良いと思います。--Frozen-mikan 2011年6月30日 (木) 02:28 (UTC)

コメント 上記開発を依頼するの節に書いてますが現状の自動承認グループを生かしつつさらに高度な保護設定を行うのであれば、現状の自動承認はそのまま若しくは少し条件を高くする（初編集から10日以内・編集回数で10-20回以内あたりを上限）程度にしておく。さらに荒らしや、初心者による編集合戦など現状では全保護相当であるが半保護の種類を増やす事によって、全保護を中等度の半保護にすることにより編集できる機会が増える可能性がある時に限って使用する半保護を設けこれの編集権限である自動昇格の条件は少し厳しい設定（1ヶ月&100編集や60日&100編集の様なもの）になっても大きな問題は無いかと思います。ただ、現状の自動承認に該当する部分を（1ヶ月&100編集や60日&100編集）といった高い昇格条件にする事は反対しておきます。あと中等度の半保護の編集権限については信用出来る利用者（グローバル権限を持つものや、wmfのプロジェクトにおいて同等以上の編集実績がある場合）等に手動で権限付与する事が出来るようにする、または問題となる行動が発生した場合に権限を停止する仕組みはあったほうがいいと思います。--Vigorous action （Ｔａｌｋ/History） 2011年6月30日 (木) 04:03 (UTC)

コメント なるほど。今の全保護を「上位半保護」にしてしまう発想もあるのですね。それなら、2ヶ月や1ヶ月、編集数制限が厳しい物でも納得出来ます。代わりに、編集権の停止で取り上げる事が出来るので、保護の柔軟性が上がると思います。現行半保護は、結局極端に重たい数字には出来ないは、ある程度認識されているようです。ただ、それだと全保護が無くなる可能性も有るので、それをどう解釈するかだと思います。--Taisyo 2011年6月30日 (木) 13:36 (UTC)

コメントいえ、保護の段階を半保護2段階、全保護の合計3つにするという事です。権限の名前はグローバル権限の名前と絡みますので変わると思いますが、イメージとしては半保護1、半保護2、全保護といった感じにする感じです。半保護1については、今までの自動承認（+α）クラスの昇格条件。半保護2の自動省昇格条件を高く設定すると言う感じです。なお、全保護についてはsysopまたは別途新しく検討されている権限が無いと編集できないという3段階にすれば、保護の方針を少し変更する及び、管理者が設定選択する手間をのぞけば今まで全保護でしか対応できな方案件も半保護2に移行する事ができそうすることにより、記事が発展する可能性が高くなるということです。また半保護2で保護された記事で問題行動を行えば、権限を一時停止する事が出来れば巻き込まれ全保護などで記事の発展が損なわれる事も少ないと考えました。--Vigorous action （Ｔａｌｋ/History） 2011年6月30日 (木) 14:08 (UTC)

コメント 先の#開発を依頼する話の「highprotect」または「rowprotect」の追加ですね。現行自動承認並みで使われる、半保護1を「autoconfirmed」で対応するとしたら、厳しい条件の半保護2は「highprotect」の採用。現行自動承認並みで使われる、半保護1を「rowprotect」で対応するとしたら、厳しい条件の半保護2は「autoconfirmed」になりますね。両方を生かすとなると、半保護1は英語版並みの4日かつ10編集が妥当でしょうか。スペイン語版並の4日50編集は少し重たいかもしれないです。半保護2は10日かつ50編集程度でしょうか。先の意見では、半保護2を「autoconfirmed」に割り当てると意見していましたので、その程度かと思います（先の意見を踏まえて「rowprotect」採用前提の文章です）。確かに、3段階なら問題はある程度解消出来ます。半保護2がある程度は全保護の代替になるので、14日かつ50編集程度でも良いかもしれないです。ただ、「autoconfirmed」は他言語版でも共通の編集権限なので、極端に剥離した値は出来ないと言う意見も有りましたので、その程度になるかもしれないです（「highprotect」採用なら、もう少し重たい値でも大丈夫だと思いますが）。--Taisyo 2011年6月30日 (木) 14:28 (UTC)

先の話を表にまとめました。

半保護1 （現行半保護）	半保護2 （上位半保護）	全保護
autoconfirmed	highprotect（仮）	protect
rowprotect（仮）	autoconfirmed	protect

赤字に関しては、新設する利用者の権限になります。「protect」は、管理者に与えられた「記事の保護及び、保護された記事の編集ができる」権限です。「rowprotect」採用の長所は日本語版以外の管理者が荒らし対応する時に、権限がない事による待機期間が短くて済む事が長所です。短所は「autoconfirmed」はグローバル権限なので、一番重たい対応でも、スペイン語版の4日50編集なので、極端に大きな値にはしづらいです。「highprotect」採用の長所は、日本語版以外の事情を考慮せずに、大きな値にしやすいのはメリットだと思います。短所は、日本語版以外の管理者は「highprotect」された記事の編集は、権限を付与しない限り無理な点が問題です。--Taisyo 2011年7月1日 (金) 14:26 (UTC)

これまでの案を総合して、私は「highprotect」採用を前提とした案を推したいと思います。理由として、「autoconfirmed」に対して現行とかけ離れすぎた値を与えることが出来ないこと、「highprotect」なら、ある程度の自由度は期待できるからです。metaの方への対応は、連絡を良くして、随時は「highprotect」編集権限を与える形で対応すればと思います。現時点では日本語版のみですが、他の言語版でも広まるような良い意見にしておけば、他の言語版との権限格差は結果として無くなると思います。ただ、「autoconfirmed」は若干の強化はいると思います。以下が個人的に思う値です。

• 「autoconfirmed」（現行半保護レベル） - 4日かつ20編集
• 「highprotect」（上位半保護） - 30日かつ50編集

バランス的に考えて、このあたりかと思いますが、どうでしょうか。--Taisyo 2011年7月2日 (土) 07:02 (UTC) , 文章修正--Taisyo 2011年7月2日 (土) 07:06 (UTC)

質問です。Taisyoさんのおっしゃっている4日及び30日というのは「初編集から」ということでしょうか？それとも「アカウント取得時から」ということでしょうか？お答えいただければ幸いです。--Haifun999 2011年7月2日 (土) 07:09 (UTC)

現行と同様の「アカウント取得時から」のつもりでした。それでも編集数制限で、ある程度の排除は出来ると思いますし、その案を「初編集から」に直すのも何だ問題はありません。--Taisyo 2011年7月2日 (土) 07:14 (UTC)

コメントちょっと待って下さい。autoconfirmedは他言語版に共通の権限ではなく、一部のグローバルグループに割り当てられていると言うのが正しいです。「IPベースの速度制限を受けない」(autoconfirmed)を上位の半保護の機能として割り当てることをしていれば、原則上位半保護で運用とか言うような極端な使用方法をしない限りjawpでのそのグループへの昇格条件が多少きびしくても大きな問題となりえないと思います。しかし逆にhightprotectを導入するのであればjawpの管理者が居ない時にstewardなどが対処する事になりますが、場合によっては自らに対して権限を付与しないと対処できない案件が出来てきます（また、スタッフ等も半保護されたページにアクセスできなくなります）。そのためグローバル権限グループの変更などが絡む話になるのでこの話はここではなくmetaの適切なページで行わなければならないと考えます。--Vigorous action （Ｔａｌｋ/History） 2011年7月2日 (土) 09:49 (UTC)

コメント 特に、三菱善次郎さん及びプログラムさんに確認したいと思います。先の意見の中で60日100編集の意見を出されていたと思います。半保護について、Vigorous actionさんが書かれたとおり「上位半保護に移行しないのであればある程度の値上昇は問題ない」としておりますが、現時点での半保護の最高値がスペイン語版の4日50編集なので、極端に差が多く、事実上の上位半保護になってしまいます。そうなると「autoconfirmed」上位の「highprotect」になるのですが、今度はmetaにお伺い及び本当に必要であるとする実態証明が必要になります。先の意見で、「autoconfirmed」で許される値の上位が7日及び10日で50編集程度ではとする意見がありますので、その程度の値でも問題ないか確認してみたいと思います。恐らく、2ヶ月寝かしアカウントの報告もありますが、50編集が有効に機能する事で荒らし行為には一定の効果が出ると思います。「rowprotect」採用前提の意見は以下になります。

• 「rowprotect」（現行半保護レベル） - 登録日から4日及び10編集
• 「autoconfirmed」（上位半保護） - 編集開始日から7日及び50編集

「autoconfirmed」は、共通の権限なのでスペイン語版の4日50編集を極端に逸脱しないレベル程度になりますが、それで問題ないか考えて頂きたいのですが。他の意見で、半保護の極端に高い値は問題であるとする意見も有りますので、お願いします。--Taisyo 2011年7月2日 (土) 11:41 (UTC)

コメント 上記の案で現行半保護の値引き上げ値の余地について、10日程度までなら何とかなると思います（14日は本当に微妙です）。編集数上限も、数割程度なら上限値は上げられるとは思います。それでは不十分であるとするなら、metaに持っていく資料を作ってお願いする形になると思います。その範囲での微調整は出来ると思いますので、日本語版の裁量で出来る値で問題ないかどうか一考して下さい。--Taisyo 2011年7月3日 (日) 01:50 (UTC)

コメント（戻します）Hosiryuhosiさんが作成して頂いたwikiで、特定ユーザーに対して半保護及び弱半保護ページの編集が出来なくなる機能が実現できることを確認しました。（誰も確認していないので）負荷の問題は何とも言えないですが、かなり柔軟な対応が出来るのでは無かろうかと思います。値の見直し提案は今回は見送ります（他の意見を聞いてみてから考えます）--Taisyo 2011年7月4日 (月) 13:07 (UTC)

コメント 私の頭の整理をしたいのと、それ以上に見ている人が分かりにくいかもしれないのでWikipedia:井戸端/subj/半保護に可変設定機能を追加することについて/案まとめ1を書きたいと思います（先にリンクを置く事で作らないといけない様に仕向ける、ある意味自分へのプレッシャーです）。内容的には、現時点での案及び、それがどの様な権限で成り立っているかをまとめたページです。--Taisyo 2011年7月7日 (木) 11:39 (UTC)

閾値の設定の方針について

質問 どのような方針で閾値を設定するか決めるため、管理者に質問します。次のような利用者に対してどのぐらいの割合で時間や手間を使っていますか。

1. 性急な編集をする利用者
2. LTA以外の荒らし
3. LTA

--プログラム（ノート/履歴/ログ） 2011年12月20日 (火) 13:26 (UTC)

上記の質問ですが、管理者の一人の意見としてお聞きいただければと思いますが、上記の番号にあるものをどのぐらいの割合や時間や手間でとおっしゃいますが、それはその時々で変わりますというか基本的に管理者というのはある案件に対してに動きます。何かの事案があり依頼があるまたは荒らしの兆候がある、なんらかの方針に抵触するような投稿がある（3RRなど）を発見したときに初めてなんらかの管理者としての行動が出てきます。また荒らし系の対処はその荒らしについてある程度の理解が必要なため、白紙化や不適切な書き込みなど明らかな場合を除き管理者だからだれでもできるといったものでもないでしょうし、LTAについては一件対処するのに数秒で済むものもあれば、数時間から数日かかるようなものまであり、手間や時間を単純に表現や比較するのは難しいと思います。--Vigorous action （Ｔａｌｋ/History） 2011年12月21日 (水) 08:49 (UTC)

質問 次のうちどの方針で閾値を設定すると良いと思いますか。

1. 性急な編集の対策
2. LTA以外の荒らしの対策
3. LTAの対策

この議論が再び活発化すると良いのだが・・・--プログラム（ノート/履歴/ログ） 2011年12月27日 (火) 14:05 (UTC)

閾値を設定するのに、上記の3つだけが関連してくるのでしょうか?私にはストーリーが見えません。上記以外にも、WP:BLPだとか保護に関連するものはあると思いますよ。どれかに特化するものではなく汎用的に利用できる設定が必要でしょう。--Vigorous action （Ｔａｌｋ/History） 2011年12月28日 (水) 09:55 (UTC)

これまでに出てきた値

• 4日かつ50編集
• 登録から7日経過かつ50編集
• 初編集から3日かつ100編集
• 2週間程度かつ100編集
• 初編集から60日かつ100編集

初版--Taisyo 2011年6月18日 (土) 13:53 (UTC)

投票に先駆けて

これまでの意見で様々な意見が出てきました。それらを成分別に纏めると（中間値もあえて追加しております）

• カウント開始 - アカウント登録から・初投稿から
• 日数 - 4日・1週間・2週間・1ヶ月・2ヶ月
• 投稿数 - 10編集・25編集・50編集・75編集・100編集

大体その当たりだと思います。成分別の投票なら投票方法としては楽かもしれないですが、複合要素がかみ合って決まる物なので、その要素を全て組み合わせた投票になるのかなと思います。その時に、全ての要素を組み合わせた形で選択肢を作る事になると思います。選択肢が膨大になると思いますが、複数投票可能でどうかなと考えております。他に良い案があればお願いします。--Taisyo 2011年6月21日 (火) 10:46 (UTC)

LTAの判定

「初投稿からカウント」がLTAに対して有効か分からないので質問します。LTAの判定はどのようにされていますか。--プログラム（会話 | 投稿記録） 2011年7月1日 (金) 10:05 (UTC)

行動パターンなどを見て、以前の荒らしユーザーと同様の行動をしていたら、判断するが正直な所です。チェックユーザーでない限りは、機械的に判定するのは難しい部分も有ります。--Taisyo 2011年7月1日 (金) 14:26 (UTC)

では、普通の編集者のように振る舞って半保護されたページを編集できるようにしてから、荒らしを行うLTAも出てくる可能性があるということですね？--プログラム（会話 | 投稿記録） 2011年7月2日 (土) 04:33 (UTC)

そのようなLTAが出現する可能性もありますが、少なくとも現状よりは荒らし行為を行うのが大変になるはずで、現状よりはマシな状況になると考えます。ここで話し合われているのはLTAに対する根本的な対策ではなく、あくまで現状よりマシな状況にするための対策であると認識しています。--Haifun999 2011年7月2日 (土) 04:41 (UTC)

私は話を聞いたことがあるレベルで、噂程度のことしか話せないのですが、英語版で荒らしユーザーが猫をかぶり、管理者権限を獲得した後で荒らし行為を行った話を聞いたことがあります。極端な話ですが、完全になくすことは無理ですし、誤動作の問題も深刻になると思います。現状よりも、数が大幅減になれば管理者が残りを手動で対応しやすくなると思いますので、良くなると思います。荒らし行為をするために真面目な編集を数こなすのも非効率な話ですので。そのような考えです。--Taisyo 2011年7月2日 (土) 07:02 (UTC)

もう一つ補足として、一般管理者の場合はIPは分かりません。よって、良い子しているブロックユーザーを見抜く手段は存在しないです。良い子でなくても、良くある初心者の癖と同様であれば大目に見る事も多いです。IPが分かるのはチェックユーザーで、コミュニティの信任だけではなく、ウィキメディア財団に対する身分証明も必要となります。そのために、チェックユーザーに関するルールの例外は作りにくく、ハードルも高い物になります。明らかに荒らし行為をしている場合は類する行為で対応出来ますが、そうでなければ例え疑わしくても、証拠がない以上、対応出来ない例も存在します。--Taisyo 2011年7月16日 (土) 14:12 (UTC)

技術的な確認

2段階保護で話が盛り上がっているところに水を差すようですが、そのような設定が可能であることは、誰かきちんとdevなりsysadminになり確認しましたでしょうか？つい先ごろ、あるdevと個人的にやり取りをしていた中で、このことを思い出して聞いてみたら彼は「（触ったことないから詳しくは分からないけど）それは普通の設定じゃできないんじゃないの？」と言っていました。mediawiki-lなりwikimedia-lなり、他の人が確認できる公開の場所で、一度きちんと確認をとってから話をすすめるべきと思います（※MediaWiki的には可能でも、負荷などの理由からウィキメディアプロジェクトやjawpでは厳しい、という場合もあります）--青子守歌（会話/履歴） 2011年7月3日 (日) 02:08 (UTC)。

負荷などと言っておられますが権限グループを増やすだけの話ですので、負荷自体は通常の保護・半保護と変わりはありません。問題となるのは新たな権限グループとグローバル権限の整合性だけだと考えています。負荷を言うならAbuseFilterの方がシステム的な負荷が高いでしょうし、開発に至っては数少ない開発者への負荷がかかると認識しますがいかがでしょう?だだ、確認する事を反対するわけではありません。--Vigorous action （Ｔａｌｋ/History） 2011年7月3日 (日) 02:32 (UTC)

ノートに設定例を書いてみました。これでMediaWik上はいけるはずです。--Hosiryuhosi 2011年7月3日 (日) 06:01 (UTC)

Hosiryuhosiさん。ありがとうございます。元々（ウィキペディア上では）技術屋でないので感心してばかりです。パッと見た目、あっさり解決した様に見えますけど、実際の所は機能追加前と追加後でサーバーに対する負荷がどのくらい増えたのか気になります。プログラム自体はそう長いものでは無いと思いますけど、プログラムのループによっては意外と負荷ある可能性も有ります。私が調べるよりかは、Hosiryuhosiさんが説明した方が良いと思いますので、お願いしてみたいと思います。あと、プログラムを組むのは最終決定時で良いので、もし以下の仕様で組んだ時の負荷状況なども、大まかに教えて貰えたらと思います。技術的に詳しくない人も多く見ていると思いますので、素人的な質問で申し訳ないですがお願い致します。

案	案の内容
案1	*（新）承認された利用者（現行「承認された利用者」-「autoconfirmed」） - 登録から4日 * 弱半保護編集者（「rowprotect」） - 登録から4日かつ10編集 * 半保護記事編集者（「autoconfirmed」 ） - 投稿開始日から7日かつ50編集
案2	*（新）承認された利用者（現行「承認された利用者」-「autoconfirmed」+「rowprotect」） - 登録から4日かつ10編集 * 半保護記事編集者（「autoconfirmed」 ） - 投稿開始日から7日かつ50編集

以上です。--Taisyo 2011年7月3日 (日) 13:04 (UTC)

負荷の調査ですか。負荷の調査はやったことがないもので、方法がわかりませんね。。jawpとは規模自体が違いますので、現状3人程度しか登録していないウィキで、負荷の調査を行ったとしても、大した結果が得られるとは思わないのです。設定例は書いてありますので、時間があって負荷調査が可能な人はお願いします。--Hosiryuhosi 2011年7月3日 (日) 14:02 (UTC)

Hosiryuhosiさん。負荷の質問失礼しました。それと、Hosiryuhosiさんが用意して頂いたwikiで新権限のテストを行いました。細かい仕様は別にして、技術的に（負荷を除いては）実現可能であると実感しました。あと、権限追加で使いにくくなる事も特にありませんでした。後の課題は、負荷問題（高い意味ではなく、不明である）と設定の問題かなと思います。--Taisyo 2011年7月4日 (月) 12:07 (UTC)

権限の制限・否承認の発想

すでにいろいろな意見が出ており議論も進んでいる状況ではありますが、ざっと議論を流し見たところこの発想がなかったようなので、今更ではありますが提案させていただきます。自動承認に必要な条件は英語版と同程度の比較的ゆるいものとし、その代わりに所定の期間内に一定の投稿数に達しなければ自動承認しない代わりに「自動否承認となった利用者（or自動承認で制限された利用者）」として「自動承認された利用者」に与えられる権限の一部またはすべてを自動的に制限するというものです。ノルマを定めて制限を与える目的は、新規アカウント取得者に対して目的の正当性をその行動をもって示していただくことと、寝かしアカウントに対して寝かす暇を与えないことです。この観点から、期限は極力短く必要投稿数は多すぎない程度が望ましいと考えます。自動承認ではどんなに条件を重くしてもいずれ条件さえ満たせれば承認されてしまいますし、条件ばかり重くなっても大半を占めるであろう正当目的のアカウント取得者への負担増のデメリットの方が大きいものと考えられますが、この案であれば不正目的によるアカウント取得者を警戒しつつ、正当な取得者の利便性もある程度保てるのではないかと考えています。

長文で見にくくなりそうになってきたので以下ワタシの考えを箇条書き気味に書き出していきます。

• 制限ノルマ設定による負担増の可能性

編集者としてアカウント取得を希望する者にとって、ある程度の編集数ノルマであれば大きな負担にならないものと考えます。

期限については、アカウント取得者のモチベーションを考慮すると登録日を起点とし短いほうが望ましいと考えます。

この事から、承認で慎重を期するために多くの日数と投稿数を要するのと比べれば増える負担はかなり少ないものと考えます。

• ゆるいノルマは不正利用者にもやさしいのでは？

数字上ノルマ設定はゆるくなっていますが、その先には「否承認or制限利用者」というペナルティーが待っています。

それを考慮すれば、投稿する為にアカウントを取得した正当利用者と、権限取得の為に投稿しなければならない不正利用者とでは心理的負担に大きな差があるものと考えます。

また、ノルマ達成の為だけの投稿では何かしらアラが出る可能性が高くなると考えられます。

さらに、ノルマ達成後にピタリと編集がとまればそれは疑ってくれと言っているようなものです。

• 正当な利用者がノルマを達成できなかったら？

ワタシの案は自動承認がされない（あるいは実質的にされない）だけであって、手動による承認等で対応可能と考えます。

ただし、手動承認にあたっては別途重めのノルマや条件を課した上で、自ら承認依頼を行うべきと考えます。

• それでもめげない不正利用者には･･･？

入り口だけで全てを防ぐのは無理だと割り切って別途対策を立てるしかないでしょう。

しかしながら、先述の通りアラが出やすくなることで事前に発見しやすくなる可能性は期待できると思います。

また、先述の手動承認のように、後から手動で制限の付与または承認の取消しなどの方法があっても良いのではないかと考えます。

長くなった上にシステム面・技術面の事情はほとんど考えずに書いてしまいましたが、現状の自動承認が承認されることが前提の仕組みになっていることを省みて、適切に対応しなければ絶対に承認されない仕組みにすることで、あえて半保護を段階的にする必要がなくなる、あるいは段階的な半保護と組み合わせてより効果的な仕組みにできるのではないかと考えました。--イイダムシ 2011年7月20日 (水) 08:24 (UTC)

よまさせていただきました。技術的な面は置いておいて、少し感じた事を書かさせていただきます。Wikipediaの編集者はあくまでボランティアであり個人の都合・興味で編集する・しないの自由があると思います。まだ管理者などの特殊権限グループに属する者がアカウント乗っ取り防止のために一定期間活動が無い場合に権限を除去するなどの制限の場合は許容範囲のようですが、ご提案の内容であれば、一定期間内に編集ノルマを達成しないと権限停止処分を課すと言う事ですので「方針に従う限り、誰でも自由に編集できます」というWikipediaの趣旨からすると少しなじまないように思います。また編集回数だけですと、{{Preview}}や{{一括}}などを貼られるような編集でもノルマを達成する事が可能になりますので、編集回数が少し足りない人がわざとその様な編集をするなどを危惧します。

アカウント作成時にクレジット番号の登録とかその様な手段が無い限り入り口だけで防ぐことは難しいでしょう。そこで荒らしなどの不正利用目的者の編集は抑止し、かつその他の利用者の編集はできるだけ止めない方法として半保護に段階を設ける設定を提案されているのだとわたしは考えています。（自動昇格条件に編集回数などのノルマはありますが、達成期間が決まっていないためまだ達成しやすいでしょう。）利用者:イイダムシ（会話 / 投稿記録 / 記録）さんの様に日々沢山の有益な投稿をされている方のみであれば編集ノルマを達成することに苦労は無いのかもしれませんが、1ヶ月に1-2件の新しい記事を投稿する or 大量加筆する、などの活動される様な方の場合有益な編集者であっても編集ノルマを満たさないために権限付与依頼などの手間がかかってしまう事持考えられます。その辺りの負担を考えると難しいのではないかと考えます。--Vigorous action （Ｔａｌｋ/History） 2011年7月20日 (水) 09:23 (UTC)

Vigorous actionさんが一通りの事を話されたので短めに。誤作動がやはり多いかなと思います。仕事が忙しいけど、たまの息抜きしようとしたら・・・になりそうです（考え方としたら面白い部分もあると思いますが）。詳細な値は決まってないですけど、先の案である程度は楽になると思っています。--Taisyo 2011年7月20日 (水) 15:01 (UTC)

コメントありがとうございます。しかしながら、誤解されていると思しき部分や、疑問に思える部分がありましたのでその旨書かせていただきます。

• 権限停止処分を課すと言う事ですので…＞そのようなことは一切申し上げておりません。あくまでも「権限の制限」または「（自動承認等における）否承認」です。もう少し細かく言うと、自動承認によって新たな権限が付与されている現状から、条件次第では自動承認を行わない（つまり新たな権限を付与しない）、あるいは（技術的に否承認が無理ならば）新たに利用者グループ等を作り自動承認によって付与された権限の一部または全部を制限するのはどうかという話です。これならばIPユーザーと同等以上の権限は維持されているわけですからVigorous actionさんの言うほどWikipediaの趣旨になじまないということはないかと思います。そもそも「権限停止」という観点で言うならばワタシの案よりはるかに重い「投稿ブロック」というものが存在しますし、本項の主題である半保護だって「方針に従う限り、誰でも自由に編集できます」の趣旨に反する事になります（ごく一部の方針に従わない利用者が原因とは言え、その他多くの方針に従う利用者の編集も制限されるので）。
• また編集回数だけですと、{{Preview}}や{{一括}}など…＞確かにそのリスクは否定できません。が、これはあくまでも自動承認を受ける為のノルマに過ぎません。アカウント取得の目的（精力的な編集活動）を考慮すれば大きな負担にならない程度にノルマを設定すればこのリスクは十分抑えられると思います（だからこそ期限を設ける必要があるのです）。それに、あせって権限取得の為の投稿が多くなってしまうとユーザーにとっても周りの見る目も厳しくなるリスクが発生するわけで、これが目に余るようであれば手動で「否承認」あるいは「承認取り消し」ということも可能かと思います。そうならないように、ノルマ達成が難しそうならばあせらず手動承認の手続きを目指すようにガイドライン等で促すのも手だと思います。そもそも「編集回数だけ」と言う発想ならば素の閾値上昇案にも当てはまりますし、むしろ期限がないことで不正利用者にとっても心理的余裕を持ちつつじっくりと回数を積み重ねることが可能ということであり、緩やかに事が進められる分事前に発覚しにくく、「寝かしアカウント」をじっくり暖めた「熟成アカウント」が密かに作られることも考えられます。
• （自動昇格条件に編集回数などのノルマはありますが、…
• 詳細な値は決まってないですけど、先の案である程度は楽になると思っています。＞セキュリティーと利便性は基本的に相反するものです。利便性を無視するわけではありませんが、それがそのまま不正ユーザーにも恩恵を与え付け入る隙を作ることになれば本末転倒です。
• 1ヶ月に1-2件の新しい記事を投稿する or 大量加筆する…
• 仕事が忙しいけど、たまの息抜きしようとしたら…＞大量加筆はともかくとして、編集頻度が少ない方々がアカウントを必要とするのでしょうか？必要だとして必ずしも承認される必要があるのでしょうか？編集だけならばアカウントを取得しなくてもできますし、先述の通りノルマ未達成であってもIPユーザーと同等以上の権限は残るのでその活動に大きな支障が出るとは考えられません。また、精力的な活動を希望するユーザーが承認依頼の手間を惜しむでしょうか？
• 誤作動がやはり多いかなと思います。＞元の案においても先述した「熟成アカウント」が潜伏し不発に終わる可能性が考えられます。また、アカウント作成時に承認を得るのに必要な手続き、そして承認を得なくてもできることをきちんと記して周知させることで回避できるものと考えます。

自分の案が必ずしも良いものだと思っているわけではありませんが、新たな権限を欲する以上はその行使に対して責任が持てることを示す事が望ましいと考えます。現状および元の案では最終的には特に意識することなく権限が付与される形となっており、必ずしも権限に対する責任が示せているわけではありません。ワタシの案は利用者に与えられた最低限の権限まで停止しようというものではなく、そこから踏み込むに当たって、責任が十分に持てることをより明確に示せるようにしようというものです。期限付きノルマはそのために必要なものとして、承認申請はノルマ達成が困難な利用者が自身の責任能力を示す為の救済措置として提案した次第です。なお、ワタシの案はアカウント取得そのものを阻害するものでもありませんので、最低限の権限に加えてアカウント取得による利点も（自動承認による権限の付与を除き）十分に守れるものと考えます。--イイダムシ 2011年7月21日 (木) 07:05 (UTC)

建前話も込みで。IPユーザーに関して「登録ユーザーになって下さい。そうなれば編集制限が無くなります」とお願いしている部分があります。今回の提案で、この建前の部分が崩れると思います。月に一回でも実際に登録して頂いた方には、これまで通り便宜を図って上げたいと思います。制限案でも一定の便宜は残るようですが、半保護編集条件を変えるだけでもそれなりに厳しくなりますので、それ以上はどうかなと。--Taisyo 2011年7月21日 (木) 12:56 (UTC)

それは建前云々ではなくTaisyoさん個人の解釈に過ぎないかと思われます。Taisyoさんの言う建前では「権利と義務」・「自由と責任」の関係における「責任・義務」の部分が完全に抜け落ちています。

アカウント取得が推奨される理由は自身と紐付けされるアカウントを取得することで、その責任の所在を明らかにすることができるからです（Wikipedia:チュートリアル アカウント登録、Wikipedia:説明責任、Help:ログイン参照）。それ故に、Template:アカウント作成のお願いで謳われている個人設定や利用者ページの使用が可能になり、責任の所在を明らかにしたことに伴って権限も付与されるものと解釈しています。ワタシの提案は責任の所在をより明確に示せるようにしようと言うのもであり、その為には利用者自身に一手間かけてもらう必要があるというだけの話で、その点を含めても極端に条件が厳しくなるものではないと考えます。

なお、元案でもそれなりに厳しくなるとのことですが、個人的には単純に道のりを長くしただけという印象が持たれます。もちろん、それすなわち条件が厳しくなったと見ることはできますが、長い道のりでも進んでいけばいずれは終点にたどり着きます。その観点から先のコメントで危惧する状況を「熟成アカウント」という言葉を用いて示したのですが、それに対する回答が「それなりに厳しくなりますので」でしかないのであれば、こちらの提示した問題点を一切解決できていないわけですから議論は平行線をたどるだけで、こちらとしても「話にならない」としか言いようがありません。また、「～これまで通り便宜を図って上げたい」というなあなあな発想が多分に含まれているとなれば、それがLTAにとって付け入る隙となる可能性は高く「それなりに厳しくなる」という言葉自体も疑わしくなってきます。--イイダムシ 2011年7月25日 (月) 04:00 (UTC)

例えば、自動承認の承認条件に一定期間内の編集回数をノルマとして課した場合に不都合となる点を幾つか・・・。まず一定期間内に規定数の編集をしなければ自動承認が得られない場合に起こるデメリットとして、現状の設定であれば「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha)・「ファイルをアップロード」(upload)・「ブックを共有ページとして保存」(collectionsaveascommunitypage)・「ブックを利用者ページとして保存」(collectionsaveasuserpage)・「ページを移動」(move)・「他の利用者の編集を巡回済みにする」(patrol)・「IPベースの速度制限を受けない」(autoconfirmed)・「既存のファイルに上書き」(reupload)といった機能が使えなくなります。例えばコモンズに投稿できないような屋外美術写真をuploadしたくとも出来ないなどの問題や、改名提案しても移動する事が出来ないなどの弊害が出てくるでしょう。また手動で権限グループを追加するという意見も出ておりますが、編集フィルター権限付与申請やBot使用申請などをみてもお分かりかと思いますがなかなか意見が出ず合意して権限付与をすると言う事が難しいように考えます。またskipcaptchaが適用されないとログイン時にcaptchaを毎回入力するという面倒な手間が発生します。2段階半保護の場合の権限の付与の基準は例示しているWikimediaプロジェクトにおける活動（信任）状況などである程度判断出来ると思うのですが、同一条件で当該の付与をした場合ほとんどの人は基準を達成しないため付与できないと言う事になるでしょう。最後に、今回ご提案の内容についてのメリットとデメリットを勘案するとデメリットの方が大きく導入するのは難しいように感じます。なおわたしの記憶では自動承認の設定を変更すると、現在自動承認になっていても新たな自動承認で基準を達成していない人はたとえ登録後5年で1万編集をしてても自動承認にはならないためかなりの利用者が自動承認の対象から外れることになり大混乱を起こす事になると考えます。（たとえば、3ヵ月300件以上の編集といった設定をした場合、イイダムシさんも自動承認の枠から外れるわけです。）--Vigorous action （Ｔａｌｋ/History） 2011年7月25日 (月) 08:11 (UTC)

（インデントが深くなったので戻します）この提案について、私の考えを書き込みます。まず、一度できるようになったことを後からできなくしてしまうとすると、ウィキペディアについて詳しく知らない新規登録者にその影響が来るわけで、「ややこしいシステムだ」と混乱を招く要因になりかねません。逆に、荒らしの場合は次々とアカウントを乗り換えていってしまいますから、自動承認を取った段階で動いて、制限がかかる頃にはそのアカウントを捨ててしまうだけでしょう。つまり、このシステムを取った場合、荒らし対策には無益である上に、無用な混乱を巻き起こすだけのものと考えます。--Jkr2255 2011年7月25日 (月) 08:41 (UTC)

コメントありがとうございます。返答するに当たって再度申しあげっせていただきますがワタシが技術的な問題等は念頭におかず発言をしていますのでご了承ください。

Vigorous actionさん＞まず権限に関する問題ですが、そのことについては最初に「一部または全てを制限する」と申し上げています。つまりは自動承認とならなかったからといって必ずしも全ての権限が与えられなくなるというものではありません。これは利用者グループを新たに作る等で対応可能かと思いますが、そういう意味では半保護編集以外の権限も含めて2段階（人によっては飛び段）で取得するような形になります。よって、自動承認を得られなかった利用者にどこまでの権限を認めるかという取り決め次第とは言えこの点は問題ないものと考えます。続いては手動承認の件ですが、正直自分でもここが一番のネックだと考えています。場合よっては手動承認にこだわらず2段階で自動承認の判定を行うという考えもあります。つまり1段目の承認では期限付き投稿数ノルマを課し、2段目では期限を設けず日数経過と投稿数をもって承認するというものです。2段目の承認に関しては先述の通りの懸念があることから手動承認が望ましいと考えこれを提案させていただきましたが、必要とあれば修正されるべきですし、そのための議論の場であると考えています。そして最後にデメリットの件ですが、まず、自動承認基準の設定を変更したとき過去にさかのぼって判定されることについてはワタシの念頭にありませんでした。ただし、それを踏まえても基準設定の問題に過ぎない部分もあるかと思われます。これも最初に申し上げましたがノルマはその性質上期限は短く投稿回数は無茶にならない程度（4日で投稿10回程度）が良いと考え、その短い期限ゆえにこの段階で正当な利用者と不正な利用者の差が現れやすくなるものと考えています。ですので、せっかく作ったアカウントを（有為無為問わず）よっぽど活用していないということでもない限り対象から外れるということは極力避けられるものと考えますし、そろこそ先述の2段階での自動承認の判定など回避策を出そうと思えば出てくるものと考えます。

Jkr2255さん＞ワタシの読解力不足なのか正直申しまして、何が言いたいのかさっぱりわかりません。この節に書かれている事からワタシの案に対するものと考えるべきなのでしょうが、当てはまっているようないないような、また元案にも当てはまっているようないないようなとなんとも理解しがたい内容です。できればもう少し具体的にコメントしていただければ助かります。あと、混乱するから新しい仕組みづくりは止めとこう的な内容になっていますが、もしそうならばその発想は的確ではないと思います。既存のシステムに不備があるならこれを是正するのはむしろ自然なこと、直さなければ後々問題がより大きくなるだけですし、新しいシステムを適用するに当たっては十分な告知が成されるはずです。逆に、既存のシステムで十分に対応できるということでしょうからその考えを出してくださいとも反論することができてしまいます。

まとめ＞ここまで数々のコメントを頂きありがたい限りなのですが、率直な感想として皆さんワタシの案に対して難しく考えすぎなのではないかと感じます。ワタシの言葉足らず（逆に余計なことばかり言い過ぎて？）うまく伝わってない部分があったのかもしれないので改めて私の考えの要点をあげてみます。

1. 権限を取得する上でその責任を明確に示せる仕組みにしてはどうか？
2. 自動承認を単純な条件だけで運用するから寝かしアカウントが作られるのではないか？
3. 新たな利用者グループを作りつつ半保護を2段階に設定するよりも、新たな利用者グループを作ることで権限の付与を2段階（以上）にする方が運用面も含めて効率が良いのではないか？
4. 承認する仕組みがあるなら否承認や承認取り消しの仕組みがあってしかるべきでは？また自動があるなら手動があってしかるべきでは？
5. もちろん既存の正当な利用者らには極力迷惑がかからないようにするべき。

以上の事を実現するにはということで今回の案を出させていただいた次第です。なまじ具体的な方法に言及してしまったが故にうまく伝わってなかった部分があるかと思いますが、必ずしもこの方法だけにこだわるものではありません。元案にも懸念があることも含めて、少しでも上記のことについても考えてもらえればというのが今回の提案の最大の意図です。--イイダムシ 2011年7月25日 (月) 14:16 (UTC)

コメント まず前提として書き込みますが、私はイイダムシさんの提案を、このように解釈しました（これ自体に大きな誤解があるかもしれません）。

1. まず、新規利用者には簡単な条件で自動承認が出る
2. 自動承認後、一定の期間内で書き込み回数をチェックする
3. 回数が条件を見たさなければ、自動承認された権限の一部を制限する

このような前提で2011年7月25日 (月) 08:41 (UTC)のコメントを読んで頂ければ幸いです。

あと、このような形に限らず、「自動承認」→「自動的な権限の制限」というステップにすると、「自動承認された新規アカウント」のほうが、「たまにしか編集しないために自動承認に制限がかかってしまった、ある程度の投稿履歴を持つアカウント」よりできることが多くなってしまいます。これでは（荒らしでなくても）別アカウントを作るように事実上誘導する結果となってしまい、ウィキペディアでとるべき方策として適当ではないと考えます。--Jkr2255 2011年7月25日 (月) 14:33 (UTC)

コメントありがとうございます。おかげでJkr2255さんの解釈の誤りがわかりましたので訂正させていただきます。

1. まず、新規利用者には簡単な条件で自動承認が出る
   　→　まず、アカウントの新規取得はこれまで通りにできる
2. 自動承認後、一定の期間内で書き込み回数をチェックする
   　→　アカウント取得後、一定の期間内で書き込み回数をチェックする
3. 回数が条件を見たさなければ、自動承認された権限の一部を制限する
   　→　回数が条件を見たさなければ、自動承認されない又は承認しても権限の一部を制限する

おそらくJkr2255さんは自動承認を行った後にノルマが課せられると解釈してコメントされたと思いますが、ワタシとしては自動承認におけるチェック機能の強化を目的に、自動承認の前にノルマを課す提案をしていたことから先のコメントの内容が理解できなかったようです。ともあれ、この事からJkr2255さんの懸念する状況にはならないものと考えられます。--イイダムシ 2011年7月26日 (火) 03:12 (UTC)

イイダムシさんのご提案は以下のようなものだと解釈しましたが、それでよいでしょうか？（数字はイイダムシさんのご意見より）

• アカウント取得後4日で書き込み数が10以上ならば自動承認し、そうでなければ自動承認されない又は承認しても権限の一部を制限され、その後自動承認されるにはより厳しい条件をクリアする必要がある。

それでよいとして話を進めます。誤解が生じていた原因は、イイダムシさんが

自動承認に必要な条件は英語版と同程度の比較的ゆるいものとし、その代わりに所定の期間内に一定の投稿数に達しなければ自動承認しない代わりに「自動否承認となった利用者（or自動承認で制限された利用者）」として「自動承認された利用者」に与えられる権限の一部またはすべてを自動的に制限するというものです。

—イイダムシ、Wikipedia:井戸端/subj/半保護に可変設定機能を追加することについて#権限の制限・否承認の発想

とおっしゃったからだと考えます。自動承認されてから、「自動承認された利用者」に与えられる権限の一部またはすべてを自動的に制限することがある という誤解が生じていたのではないでしょうか。

で、誤解が生じていた原因はともかくとして、そのご提案についての意見です。初めてアカウントを取る人が、例えば4日で書き込み数が10に達せず自動承認されなかった時に、荒らしでなくても別にアカウントを作り、その別のアカウントで4日以内に10編集しようとするようになるのではないでしょうか。Jkr2255さんもおっしゃってますが（荒らしでなくても）別アカウントを作るように事実上誘導する結果となってしまうのではないかと考えられ、あまり適当では無いと考えます。

なお、アカウントを取ってから4日で書き込み数10というのは、例えばLTA:HATであれば容易に達することのある数字であり、あまり適当でないということも申し上げておきます。--Haifun999 2011年7月26日 (火) 10:25 (UTC)

私も、真面目な意味で塩漬け別アカウントを持っています（なりすまし防止・BOT予定用）。その様なアカウントを先行取得しておいて、必要時に備える考え方もあると思いますが、手動制限解除をしないと使えない事になります。面倒くさければ、再取得・・・余り利のある案では無いと思います。--Taisyo 2011年7月26日 (火) 13:40 (UTC)

Haifun999さん＞自動承認されなかった場合に別アカウントを作る可能性については、アカウント作成時に権限を取得する為だけの編集活動や別アカウント作成を行うことによる（懐疑的な目で見られやすくなる）リスク、自動承認されなかったことで発生する制限と発生しない制限、自動承認されなかった場合の（手動承認などの）救済措置などについてきちんと説明することで抑制は可能であると考えますし、ワタシの挙げた数字等はあくまでも一個人の考えに過ぎませんので柔軟に設定することでも対応しうるものだと思います。もっとも、別アカウントの可能性についてはほとんど念頭になかったものであり重要なご指摘を頂けたものと考えます。また、「例えばLTA:HATであれば容易に達することのある数字」というご指摘につきましては、「数字だけならば」という条件付きになると考えます。つまり、数はこなせても質は伴わないであろうという考えであり、これにより先述の権限取得の為だけの編集活動のリスクがもろに発生し、不正目的によるアカウント取得を早い段階で察知できるのではないかというのが狙いで、「短い期限・それなりの投稿数によるノルマ」と提案させていただきました。特に、寝かしアカウントを数作ろうとすればより質が伴わなくなり、ゼロにはできなくともこれを抑制する効果は十分に期待できるものと考えます。

Taisyoさん＞少々乱暴な言い方になりますが、Taisyoさんの塩漬け別アカウントもLTAの寝かしアカウントも基本的には同質のものと考えます。唯一の違いは想定されている利用目的ですが、そんなものは作成者の頭の中にだけ存在するものであって、実際に運用が開始されるまで全く表に出てきません。正当な目的による別アカウントまで巻き込まれるのは極力避けるべきだとは思いますが、結局は「不正利用者の為に正当な利用者まで規制の及ぶリスク」と「正当な利用者な利用者の為に不正利用者への規制がゆるくなるリスク」の2択という考え方になってしまうのではないでしょうか？その他、通常とは異なる運用方法をする以上リスクは避けられないのでは？事前の備えなのにその手続きをめんどくさがるなら本当に必要な備えなのか？そもそも先行取得の必要があるのか？等など、その内容が本心であるかは全くの別問題として、考え方を想像するだけならはいろいろ出せそうと言うのが本音です。それと、「余り利のある案では無いと思います。」という指摘ですが、ご自身に面倒がかかるからそういっているだけとも取れます。そういうつもりで書かれたわけではないとは思いますが、ワタシとしても想定するメリットはいろいろと挙げているつもりでいますので、これを踏まえて不服であるといわせてください。--イイダムシ 2011年7月27日 (水) 08:50 (UTC)

最近改正されたWikipedia:多重アカウントでは、荒らしユーザーの寝かしアカウントと、真っ当な利用者の寝かしアカウントの差別化について明記してあります。イイダムシさんは「作成者の頭の中にだけ存在するもの」とありますが、最近のルール改正で所有アカウントの明記が義務化され、私の場合は利用者:Taisyo#接続IP及び別アカウントについてにて明記してあります。その中に利用目的とかも書いておりますので、「作成者の頭の中にだけ存在するもの」て事は断じてあり得ないと申し上げます。今回改正のWikipedia:多重アカウントは英語版の輸入なので、日本語版似合う形での修正は行われるかもしれないですが、今回の例に関しては特に不満もないので、現行のルールで落ち着くとは思います。今回のイイダムシさんの案は、Wikipedia:多重アカウントに適合しているアカウントも排除する可能性があると思います。--Taisyo 2011年7月27日 (水) 10:40 (UTC)

イイダムシさんの私へのコメント前半部分についてです。「別アカウントを作る可能性については（中略）抑制は可能」とおっしゃっていますが、現状のWikipedia:多重アカウントを読むと、どんな場合であっても別アカウントを作成することは悪だと言ってるわけではなく、自動承認されなかった場合に別アカウントを作ることが現状禁止されているわけではないと考えます。したがって「抑制は可能」ではないと考えます。もちろん、アカウントが無駄に増えてしまうのは良いことではないのですが。また、初心者に対して色々説明したとしても、それらをすべて理解するのは難しく、別アカウントをとる、あるいは、Wikipediaに投稿することをやめてしまう。といった方向にしか行かないのではないでしょうか。次に、後半部分について。「数はこなせても質は伴わない」とおっしゃいますが、その「質」というのはどのようにチェックするのでしょうか？数は機械的に判断できますが、質は機械的に判断することは出来ませんので。--Haifun999 2011年7月27日 (水) 11:41 (UTC)

（インデント戻します）Taisyoさん＞アカウントの正・不正の差別化は私の認識不足でした。しかしながら、認識不足故に先のコメントで記載を避けていたことがあながち誤りではなかったと判断したことから書かせていただきます。すでに信用を得ているアカウントと紐付けされているのであれば、その別アカウントが信用を得ることには全く支障が無いものと考えます。それこそ登録1日目投稿数0回であっても問題は無いでしょう。となれば、単に自身がその信用を証明する手間を惜しむか否かの問題であるかのように思われますし、逆にその手間すら惜しむような方が本当に別アカウントを必要とするのか、あるいは必要となるのか疑問であると考えられるのではないでしょうか？
Haifun999さん＞まず、「質というのはどのようにチェックするのでしょうか？」との事ですが、その為のWikipedia:管理者伝言板であるとワタシは認識しています。ぶっちゃげヒューマンパワーに頼るという回答なのですが、先述の通り期限付きノルマを課すことで、不正ユーザーにとっては焦りの要素が加わり、それと判断しやすい投稿になるのではないかと踏んでいます。これによって早期に（それこそ寝かせる間もなく）寝かしアカウントの芽をつぶすことができるのではないかと考えた次第です。続いて、別アカウントの作成が禁止されていないから抑制できないと断じるのは少し違うように思います。安易なアカウント作成を繰り返せば（逆にそういう方だからこそ）似たような編集傾向のアカウントが立て続けに作られる形になり、目ざとい利用者がソックパペットの疑い有りとして問題視し、場合によっては正常な編集活動にすら支障をきたす可能性があることを説明すればそのリスクを理解してもらえればある程度の抑制効果は期待できると考えます。とは言え「それらをすべて理解するのは難しく、別アカウントをとる、あるいは、Wikipediaに投稿することをやめてしまう。といった方向にしか」に関しては、こればかりはどうしようもないと言わざるを得ずワタシの認識の甘さを痛感するばかりで、ワタシの案の致命的な欠点を指摘していただけたことに感謝する次第です。

今回いただいたコメントにてワタシの提案に致命的な欠陥があることを認識しましたので、これをもってワタシの提案を取り下げさせて頂く事とします。しかしながら、元案にも懸念があるという考え自体には変わりがありませんので、ワタシが発案したことが少しでもより良い方向に向かうきっかけになってくれれば幸いです。この度は不仕付けに別案を出し、場を乱すようなまねをしたこと深くお詫びすると同時に、コメントをしてくださった方に深く感謝申し上げます。--イイダムシ 2011年7月27日 (水) 12:24 (UTC)

導入に向けてするべきこと

2段階半保護で議論が進んできていると感じています。そこで以下に行うべきであろう内容を書いておきます。その他気がつかれた方は随時追加してください。--Vigorous action （Ｔａｌｋ/History） 2011年7月11日 (月) 04:58 (UTC)

2段階半保護導入決定前

1. mail:mediawiki-l（青子守歌さんの言われるmail:wikimedia-lが不明)などでの確認(推奨?）。(担当者募集中）
2. BOTを扱う事ができる管理者に、保護状態の変更ができるかどうか確認

   現行プログラムで対応出来ない場合は、BOTプログラムの修正（恐らくソースコードは配布されていると思うので、必要な修正後に再コンパイル）。コンパイラ所有者が行う必要があり

2段階半保護導入の決定

1. 導入案のどれを採用するのかの決定、自動昇格条件の決定
2. 新しく作成される権限グループ・権限の名称の決定

2段階半保護導入が決定したら

1. Wikipedia:半保護の方針・Wikipedia:保護の方針の改定

   半保護ページの編集権限停止を採用する事になれば、権限停止に関するルールの新設

2. 現状半保護されている項目の取り扱いについて
3. 現状半保護されている項目をlowprotect(仮称)に変更する場合、手動での変更は大量である事からbot作業依頼にてBotを持つ管理者へ（管理者権限グループで無いと保護設定の変更が出来ない事から）の作業依頼（場合によっては、管理者へのBotフラグ付与などが必要であるため、時間がかかる場合がある）
4. 現状全保護されている項目の取り扱いについて（全保護を続けるものと上位半保護に変更するものに分かれる？）
   • 全保護からautoconfirmedは全部移行できるわけではないので、無期限については個別審議、有期のものは自動解除でその後設定するものからでいいのでは?
     • 無期限のものでも原則移行せず、審議が必要であるとログインユーザの内の誰かが考えたものだけWikipedia:保護解除依頼あるいはWikipedia:保護変更依頼（仮称）で審議すればよいと考える
5. 現状全保護されている項目をautoconfirmed(上位半保護の仮称)に変更する場合、上記Bot作業依頼（変更する項目が大量になる場合）
6. 新しい半保護用のテンプレートの作成などの整備
7. 変更の周知
8. Help:Pywikipediabotや、AWBなどの（BOT）スクリプトの修正を依頼
9. bugzilla:への依頼

前回の議論の補足

Wikipedia‐ノート:井戸端/subj/半保護に可変設定機能を追加することについて

lowprotect設定例

• 以下にlowprotect を設定する場合の、MediaWiki設定例を書いておきます。
• "lowprotect"が編集可能になる利用者権限グループ名は一応"lowprotect" としておきます。この権限名・権限グループ名は変更できます。

WMF向け/ InitialiseSettings.php

• 行の一番先頭にある　"-"は既存設定の除去(古い設定) , "+"は追加　です。それ以外の+や-は設定項目によるものです。
• "..." は既にある他ウィキの設定記述を省略、という意味です
• [1] より設定項目名を抜き出しています。以下は設定項目の順番を意識していません。
• コメント文（灰色斜体）が多く使用されていますが、わかる人むけの解説のためです。既存のコメント文は省略しています。

//保護レベル自体の追加や変更
'wgRestrictionLevels' => array(
...
-    'jawiki' => array( '', 'autoconfirmed', 'sysop' ), // (既存コメント文省略)
+    'jawiki' => array( '', 'lowprotect', 'autoconfirmed', 'sysop' ), // (コメント文)
...
),

//利用者権限グループ "lowprotect" の作成と 権限グループ autoconfirmed のlowprotect 編集許可など
'groupOverrides' => array(
...
-    'jawiki' => array( 'autoconfirmed' => array( 'patrol' => true ) ), //(既存コメント文省略)
+    'jawiki' => array( 
+        'lowprotect' => array( 'lowprotect' => true ), // lowprotect グループ作成
+        'autoconfirmed' => array( 'patrol' => true, 'lowprotect' => true ), //autoconfirmed が lowprotect 編集可能に(必要でない)
+        'sysop' => array( 'lowprotect' => true ), // sysop にもlowprotect編集を可能に(必要でない)
+        'confirmed' => array( 'lowprotect' => true ),　//"承認された利用者"が lowprotect を編集可能に。
+    ),
...
),

//WMF独自の「自動承認」系設定
'wmgAutopromoteExtraGroups' => array(
...
+    'jawiki' => array(
// lowprotect 利用者権限グループの自動承認設定 (編集回数10回以上、かつ登録より4日経過したとき、lowprotect グループへ属す)
+        'lowprotect' => array( '&',
+                array( APCOND_EDITCOUNT, 10 ),
+                array( APCOND_AGE, 4*86400 ),
+        ),
/* ここより[1]まではwmgAutopromoteExtraGroupsでの対応が可能か、不明です。wmgAutopromoteExtraGroupsでの対応が不可能な場合は,
 * CommonSettings.php にある$wgAutopromote関連の行を InitialiseSettings.php へ移し変える必要性があるかもしれません。
 * 以下は「初編集より7日」を実現するためのものであり、通常の「登録日より7日間」である場合、この設定ではなく、別の設定になります。
 * 以下は「 50編集 + 初編集より 7 日経過したとき」、 自動承認された利用者 グループに属します。設定上書きとなるはずなので、これで大丈夫だと思いますが。
 */
+        'autoconfirmed' => array( '&',
+                array( APCOND_EDITCOUNT, 50 ),
+                array( APCOND_AGE_FROM_EDIT, 7*86400 ),
+        ),
/* [1] */
+    ),
...
),

// lowprotect 利用者権限グループを "autoconfirmed" グループ同様の扱いとする。(必要ではない)
// 意味:
'wmgExtraImplicitGroups' => array(
...
    'jawiki'  => array( 'lowprotect' ),
...
),

//管理者が利用者権限グループ「承認された利用者」の追加を可能にする。
'wgAddGroups' => array(
...
    '+jawiki' => array(
-        'sysop' => array( 'abusefilter' ),
+        'sysop' => array( 'abusefilter', 'confirmed' ),
    ),
...
),

//管理者が利用者権限グループ「承認された利用者」の除去を可能にする。
'wgRemoveGroups' => array(
...
    '+jawiki' => array( 
-       'sysop' => array( 'abusefilter' ),
+       'sysop' => array( 'abusefilter', 'confirmed' ),
    ),
...
),

一般ウィキ向け / LocalSettings.php

• 自分のMediaWikiで試したい人はLocalSettings.php へ以下の行を追加してください。
• 初期セットアップ状態(MediaWiki 1.17.0「すでに飽きてしまった、ウィキをインストールするだけです」を選択した場合)を想定して書いています。
• 他の設定が用いられたり、既に一部設定が変更されている場合、適宜修正してください。
• コメント文(灰色斜体)は除去されても問題ありません。

$wgRestrictionLevels = array( '', 'lowprotect', 'autoconfirmed', 'sysop' ); // 保護レベル追加
$wgImplicitGroups = array( '*', 'user', 'autoconfirmed', 'lowprotect' ); // autoconfirmed と同様の扱い
//以下権限グループ設定
$wgGroupPermissions['lowprotect']['lowprotect'] = true;
$wgGroupPermissions['autoconfirmed']['lowprotect'] = true;
$wgGroupPermissions['sysop']['lowprotect'] = true;
$wgGroupPermissions['confirmed']['lowprotect'] = true; // 承認された利用者の設定 (lowconfirmed)
$wgGroupPermissions['confirmed']['autoconfirmed'] = true; // 同上 (autoconfirmed)
// 以下自動承認等条件設定 ([1] か [2] のみ設定してください)
$wgAutopromote = array(
// [1:Start]$wgAutoConfirmCount, $wgAutoConfirmAge 設定を残す場合
	'autoconfirmed' => array( '&',
		array( APCOND_EDITCOUNT, &$wgAutoConfirmCount ),
		array( APCOND_AGE, &$wgAutoConfirmAge ),
	),
// [1:END]
// [2:Start]この設定にて直接 autoconfirmed 期間を設定する場合。
	'autoconfirmed' => array( '&',
		array( APCOND_EDITCOUNT, 50 ),
		array( APCOND_AGE_FROM_EDIT, 7*86400 ),
	),
// [2:END]
        'lowprotect' => array( '&',
                array( APCOND_EDITCOUNT, 10 ),
                array( APCOND_AGE, 4*86400 ),
        ),
);
// 管理者(sysop)が 承認された利用者 (confirmed) の付与(Add)と剥奪(Remove)を可能にする。
$wgAddGroups['sysop'] = array( 'confirmed' );
$wgRemoveGroups['sysop'] = array( 'confirmed' );

• 上記の設定例では、既存の自動承認された利用者(autoconfirmed)を「初編集から7日、50編集」、lowprotect(新設) を「登録から4日、10編集」としてあります。
• また、上記では「承認された利用者」のグループを管理者が追加できるようにしてあります。
• 試したい方は 上記のLocalSettings.php向け設定例の自動承認条件部分のみを、作動確認用に短期間設定にしているテスト用ウィキを公開しています(議論終了後削除します)。--Hosiryuhosi 2011年7月3日 (日) 06:00 (UTC)

案まとめ

Wikipedia:井戸端/subj/半保護に可変設定機能を追加することについて/案まとめ1

現行の半保護を踏まえて、新たな案がどのような案なのか、権限を踏まえて説明します。--Taisyo 2011年7月7日 (木) 12:45 (UTC)

現行

現時点の利用者グループの条件は以下の通りになっています。

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload)	新規登録から4日経過

その中の「半保護されたページの編集 (autoconfirmed)」が、半保護記事編集に関係し、その条件が新規登録から4日になっていることが、現行の半保護記事編集制限になっております。以上の表を、取り消し線及び赤字の追記で、分かりやすく改正点を説明します。

改正案

単純閾値上昇案

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload)	新規登録から4日経過 案1)新規登録から4日経過かつ10編集（英語版同様） 案2)新規登録から4日経過かつ50編集（スペイン語版同様）

実現性は一番高く、既に他の言語版で採用されている案です。ただし、半保護のみではなく、他の条件（特に画像のアップロード）等の条件も上がるので、大幅な値の上昇は難しいかもしれません（上限としてスペイン語版並の「新規登録から4日かつ50編集」程度?）。また後記する、半保護編集の制限機能も採用しにくいと思います。

半保護編集者案

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload)	新規登録から4日経過
半保護記事編集者（仮）	「IPベースの速度制限を受けない」(autoconfirmed)	新規登録から4日経過かつ10編集など

半保護編集に関する権限を分離する案です。「autoconfirmed」はグローバル権限なので、既にある値に対する剥離はしにくいと思いますが、グループにも割り当てされてますし、その他必要な人に手動で付与できるようにすれば上限値は多少上げやすくなります。後記する、半保護編集の制限機能も採用しやすいと思います。

弱半保護・半保護編集者案1

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload) 「弱半保護されたページの編集」(lowprotect)	新規登録から4日経過
半保護記事編集者（仮）	「IPベースの速度制限を受けない」(autoconfirmed)	新規登録から4日経過かつ10編集など

半保護編集に関する権限を分離し、さらに現在の自動承認された編集者に弱半保護を追加する案です。先の案同様に「autoconfirmed」はグローバル権限なので、既にある値に対する剥離はしにくいと思いますが、上限値は「半保護編集者案」よりさらに上げやすくなります。後記する、半保護編集の制限機能も採用しやすいと思います。

弱半保護・半保護編集者案2

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload)	新規登録から4日経過
弱半保護記事編集者（仮）	「弱半保護されたページの編集」(lowprotect)	新規登録から4日経過かつ10編集など
半保護記事編集者（仮）	「IPベースの速度制限を受けない」(autoconfirmed)	初回編集から7日経過かつ50編集など

上の案より、さらに半保護記事編集者・弱半保護編集に関する権限を両方を分離した案です。先の案同様に「autoconfirmed」はグローバル権限なので、既にある値に対する剥離はしにくいと思いますが、上限値は「弱半保護・半保護編集者案1」よりさらに上げやすくなります。後記する、半保護編集の制限機能も採用しやすいと思います。

強半保護編集者案

利用者グループ	内容	グループになる条件
自動承認された利用者	「CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行」(skipcaptcha) 「ファイルをアップロード」(upload) 「ブックを共有ページとして保存」(collectionsaveascommunitypage) 「ブックを利用者ページとして保存」(collectionsaveasuserpage) 「ページを移動」(move) 「他の利用者の編集を巡回済みにする」(patrol) 「IPベースの速度制限を受けない」(autoconfirmed) 「既存のファイルに上書き」(reupload)	新規登録から4日経過
強半保護記事編集者（仮）	「強半保護されたページの編集」 (highprotect)	初回編集から30日経過かつ50編集など

現在の「自動承認された利用者」をそのままに、強い半保護を入れた案です。グローバル権限グループに権限が割り当てられていない半保護なので、値の縛りはない反面、採用に関してはmetaへのお伺いの上でグローバル権限グループに権限付与することについて合意がないと採用できない（要は、必要性の説明や参考となるデータの準備が必要である）、採用はしにくい案です。

半保護編集権限の停止

元々「confirmed」（新規ユーザーが半保護編集する権限）を手動で与えることができます。逆に「restricted_ac」（既存ユーザーの半保護編集する権限を制限する）を手動で与えることもできます。上記の案の組み合わせで、これまで以上の記事の保護の運用ができるようになります。

利用者グループ	内容	グループになる条件
承認された利用者 (confirmed)	CAPTCHAが必要な場面でCAPTCHAをスキップして操作を実行する (skipcaptcha) ファイルのアップロード (upload) ブックを共有ページとして保存 (collectionsaveascommunitypage) ブックを利用者ページとして保存 (collectionsaveasuserpage) ページの移動 (move) 他人の編集を巡回済みにする (patrol) 半保護されたページの編集 (autoconfirmed) 存在するファイルの上書き (reupload) 「弱半保護されたページの編集」 (lowprotect)	グローバル権限を持つ利用者・homewikiがjawpではないがjawpで有効なbotフラグを持つBotのオペレーターなどに対して手動で付与

利用者グループ	内容	グループになる条件
承認の取り消されされた利用者（仮）(restricted_ac)(仮)	弱半保護されたページの編集 (lowprotect) 「IPベースの速度制限を受けない」(autoconfirmed)	問題となる行動を行った者に対して手動で付与することによって取得していた権限が停止される。

手動で与える権限グループの一例を書いておきます。さらに審議する内容としてどの権限グループに属するものが手動付与できるのか（承認された利用者・承認の取り消された利用者それぞれ）を決める必要があります。（例:管理者が付与するのか、ビューロクラットのみなのか、それとも荒らし対策面から見てCUがいいのかなど）

他に組み合わせられる案

個人的には、利用者登録を厳しくする（複数個取得する時に、メールアドレス要求を行う）などを組み合わせるのは有効に思います。

停止グループの方には自動承認で与えられた権限すべてをいれるか、「ページを移動」(move)・「ファイルをアップロード」(upload)だけを上記に追加する方法もあるかと思います。--Vigorous action （Ｔａｌｋ/History） 2011年7月9日 (土) 06:32 (UTC)

今回の案とは直接は関係ありませんが、「ファイルのアップロード (upload)」の手動剥奪（権限の停止）に関する仕様も出来るとは思います。もっとも、運用を考えたら難しいかもしれないですが。--Taisyo 2011年7月11日 (月) 12:00 (UTC)

ボツ案

最初に提案した、半保護を完全可変にする案ですが、利用者設定の関係上きわめて難しい事よりボツ案になっています。

---

初版--Taisyo 2011年7月7日 (木) 12:45 (UTC)

権限と権限グループが混乱していたようなので修正。及び手動グループの内容を追加。--Vigorous action （Ｔａｌｋ/History） 2011年7月9日 (土) 06:32 (UTC)

すいません。どうも頭の中で混ざる部分があります（議論が長い私でこの有様ですので、よりわかり易くする工夫も必要に思います）。--Taisyo 2011年7月9日 (土) 07:04 (UTC)