」と出るような仕組みにするとか。こんなウィザードを作り込むのは大変だろうと思いますが、少なくとも「脚注節の設置、脚注ヘルプ、Reflist」、不可視な部分である「Normdaten」が新規立項や赤リンクを押した時に自動挿入されない(不要であればあとで削除編集するのは許可でも良いと思うんです)のは、システム的に古き良きおおらかさを通り越して、スマホ書き込みが急速に増えた今となっては、不親切極まりないです。「デフォルトソート」がない項目もbotでどうにかなりそうな気もしますけれども。「中の人」の常識はPC版が暗黙の念頭にあって、でも、現実はスマホ書き込みが急速に増えてしまっている。これは世界的にもう止めようがない潮流なわけです。そこでの軋轢が顕在化しているのだと思います。ここを乗り越えねばWikipediaは恐竜化でしょう。今の時点ではモバイルビューだと記事末尾の横長型テンプレートは一切表示されないとか、記事同士の導線確保や記事の同一性保持にも違いが出てしまっているわけで。このままでは「中の人」はインターネット老害ばかりだよね、と見向きもされなくなり、若い新規編集者を吸引する力はなくなって実際的な運営はできなくなる。それは今後5年以内でしょう。※なお、私が中の人になりきるのは怖い、という違和感の表明をしていることはそのリンク先でご確認ください。このサブジェクトの表面的な提案については「どちらかと言えば反対」ですが、この提案に込められている(であろう)危惧の感触や、何らかの解決を模索せねばという方向性については「賛成」です。その解は、おそらく、オートメーション化の推進という技術陣に対して高負荷を要求する方法でしか対応は難しいだろうという予感はあります。ルールに反して話題のスコープを拡大・拡散させてしまったことにつきましてはお詫び申し上げます。(UTC)「査読システムの導入是非」という主題から大きく外れていますので、提案したいのであれば別に話題を立ててください。(UTC)(コメント)確かに、数年後に削除依頼が破綻するような事態になることを防ぐことは重要でしょうが、その方法は...少なくとも半保護と被る公開保留(仮)ではないと思います。changesに改めて目を通してみました。以下は、簡単なまとめです。私自身の理解のために書いたメモ程度ですが、何かの参考になれば幸いです。おかしな部分がありましたらご指摘ください。user」になる(英語版では)。※以下便宜的に「レヴュアー」と記述。changes(以下便宜的に「保留中の変更」と記述)」をチェックする権限を付与された利用者(英語版では)。英語版では、「レヴュアー」の権限を兼ね備える。protection(以下便宜的に「変更が保留される保護」と記載)」と呼ばれる保護を施した記事では、一定条件化において、編集がそのまま記事に反映されずに「保留中の変更」の状態となる。以下は、適用中の記事における状態の推移の例。新規利用者」が編集⇒「保留中の変更」がある状態となる。「変更が保留される保護」を施された記事を、2の「自動承認された利用者」が編集⇒通常通りに編集が反映される。新規利用者」が編集⇒「保留中の変更」がある状態のままとなる(保留された記事が複数版溜まっていく)。「保留中の変更」がある状態になっている記事を、2の「自動承認された利用者」が編集⇒「保留中の変更」がある状態のままとなる(保留された記事が複数版溜まっていく)。revision(以下便宜的に「承認」と記載)」⇒保留されていた編集が反映される。changes(以下便宜的に「否認」と記載)」⇒保留は反映されずに、最後に承認されていた記事に戻り、「保留中の変更」がなくなりAの状態へ戻る(通常の「revert」とは別の処理)。「保留中の変更」がある状態になっている記事を、2の「自動承認された利用者」が、最後に承認されていた記事へと「revert」する⇒最後に承認されていた記事に戻り、「保留中の変更」がなくなりAの状態へ戻る(通常通りに「revert」が行える)。levelsを参考とした。userを参考とした。questionsを参考とした。管理者は、「レビュアー」と同様、Cのように「承認」と「否認」を行うことができる(参考:Effect_of_various_protection_levels)。changes」に関しては、2の「自動承認された利用者」と特に変わりない権限しか持たない。confirmed」という保護があり、この保護が施された記事を編集できる権限がある。「レビュアー」による「承認」と「否認」について上記のC-1~2ではごく簡略に記載したが、保留された記事が複数版溜まっているような場合、それぞれの版について、「承認」と「否認」を行っていく処理になる。「承認」前に、引用の追加や一部削除といった編集を行った版を「承認」することも可能な模様(時間がかかる場合には推奨されない)。editsを参考とした。)「レビュアー」について「レビュアー」に求められているのは、記事に対する破壊行為や、明らかに不適切な編集をチェックすることにあり、専門的な視点は求められず、主なチェック基準は、存命人物の伝記に反するもの、荒らしや無意味な記述に類するもの、著作権侵害への対処が必要なもの、法的な脅迫や個人攻撃、また名誉毀損に当たるもの、といった内容になる。載せないといった方針への準拠すら保証する必要はない。editsを参考とした。(UTC)223.218.246.6さん、大変な手数をかけておまとめ下さり、ありがとうございます。積み上がる各記事が、それぞれいろんな状態(プロパティ)になる、ということがよく理解できました。こんな面倒くさいものは管理者権限アカウントの保守作業にはより負荷がかかるだけだと理解できました。6144さんが「その方法は...」(違うんじゃないか)と仰った真意もそこにあるのだろうと得心できました。223.218.246.6さんのおかげです。いうことで「査読システムの導入是非」という主題については反対を表明します。全体像、技術陣の人的リソースのキャパや交渉など、考えなければならない問題があまりにも多く、大きすぎる問題で、ほとんど何も知らない私の器ではなさそうです。本職でコンサル業をやっているような方でないと取り纏めは難しいのかもしれないな、と存じました。言いたいことはあるのですが...。それなりの経験を積むまでは、自分の小さな器量の範囲でモゴモゴいうしかできそうにありません。(UTC)情報ありがとうございます。私も管理者の負担が増すだけだと思いますので、査読の導入に反対いたします。(UTC)その7[編集]私なりに、本件に関する見解をまとめてみました。現時点で求められている機能性など(抜けがありましたら申し訳ありません)1)問題点が明白な投稿の抑制2)保護されている記事の編集について、手続きや操作の簡便化(「Drafts」については、本件の範囲から逸脱するとのことのため割愛させて頂きました。考察1)について、英語版での運用に倣うのであれば、a)wikipedia全体での、問題点の明白な投稿の抑制には繋がらない。新規利用者」について言えば、単独での編集申請が可能である利点がある。b)「自動承認された利用者」について言えば、「半保護」であれば通常通り編集できるものが、「保留中の変更」がある状態にあると、編集が保留されるという問題が考えられる。本機能は記事の「保護」機能に相当することから、この「保護」を設定する際に保護機能による制限があることとのトレードオフを考えた上で、保護の適用の要否や保護の種類を決定するだけのものに過ぎない。c)前項「2)-b」について、保留されているのが、明らかないたずら投稿などであれば一般利用者であっても「revert」できることから、ルールの制定によっては、この問題の改善を図れると想定される。d)前々項「2)-b」について、そもそも、明白な「否認」対象(単純ないたずら投稿を含む)については、単純なチェックと簡単なボタン操作によって「否認」されることから、問題投稿自体減る可能性があるとするのはいささか楽観的過ぎるのだろうか?e)編集の反映について、労力の減少が見込める。権限保持者であれば、ボタン操作のみによって記事への反映が可能である。チェック基準が限られることから、内容精査についての労力も減ると考えられる。f)関連する労力削減として、削除件数を減らせると想定される。削除が必要とされるような編集についても、記事に反映されることなく抑制されることから効果は大きいと想定される。3)について、人的資源の不足は否めないが、保護機能の選択肢が増えるに過ぎず。適正な運用を行うことで、寧ろ削除等の作業量は減らせると想定される。「レビュアー」を拡充していくに当たり、管理者に求められるのとは資質やノウハウ、また意欲分野の違った人的資源の登用が想定される。4)について、本機能は保護機能の一種であり、wikipedia全体ではなく、必要に応じて、この保護の必要性があると判断された記事を保護するのに用いられることになると想定される。wikiの即時編集性を損なうものとは考えにくい。5)について、英語版に倣った運用とした場合、「否認」の対象はかなり明確であるように思われる。権限の使用が不適当であると考えられる事例があった際には、権限の不正利用(あるいは誤操作等)として、事例ごとに対応していくようにすれば運用は可能と想定される。6)について、「4)」に同様に、wikiの即時編集性を損なうものとは考えにくく、寧ろ、この保護が必要とされるような記事においては、記事が荒らされることを憂いている利用者も少なくは無いと想定されることから、一概に利用者離れの要因とは考え難い。この保護によって、利用者離れが起こるのであれば、「保護」や「半保護」も同様の理由によって利用が難しいものとなるため、保護機能の運用次第であると想定される。7)について、英語版に倣った運用とした場合、「否認」の対象の多くはフィルタでの対処は難しいか、あるいはフィルタの設定を個別に行う必要が生じる(あるいは設定が困難)と想定される。そのような意味合いからは、寧ろ新たなフィルタを設定する機会を減らせる可能性がある。8)について、抑制される投稿は半保護とほぼ同じ範囲になると考えられる。利点(編集の容易性)がある半面、増える作業(「保留された編集」のチェック)があるが、また一方では、減少する作業(主に「削除」)があるとともに、人的資源としてこれまでと違った人材が望める可能性がある。「半保護」を廃するわけではないため、選択肢の一つとして追加することで、的確な運用をすれば寧ろ全体的な総作業量の低減が望めると想定される。BLP違反」との旨の運用指針がある。新規利用者』による、編集頻度の低い記事における、BLP違反」に対する対処における選択肢の1つとして用いるのが、よいと想定する。理由としては、a)「存命人物の伝記」は、対象が存命であることから、低頻度であっても更新が発生する可能性が高い。b)「否認」の対象として、「存命人物の伝記に反するもの」が明確に含まれていること(英語版に倣うならば)。該当の記事における迷惑投稿では、場合により、迷惑投稿の内容が「削除」対象にまで及びやすいと想定される。c)前項「9)-b」に関連して、削除依頼などで活躍されている方々から、「レヴュアー」を募りやすと想定される。d)編集頻度の低い記事であっても、該当記事では粘着されるケースがあり、対処として適当なものとなる可能性が高いと想定される。(UTC)その8[編集]結構、長くなっていたため、区切りを入れました。(UTC)「https://ja.wikipedia.org/w/index.php?title=Wikipedia:井戸端/subj/「査読システム(?)」を導入してはいかがでしょうか。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。