ウィキペディア：保留中の変更

管理者は、重くて永続的な破壊行為、生きている人の経歴の違反、または著作権を侵害するコンテンツの挿入の対象となるページに、保留中の変更保護を適用できます。保留中の変更の保護は、まだ発生していない違反に対する先制措置として使用したり、コンテンツの紛争で未登録のユーザーよりも登録済みのユーザーに特権を与えるために使用したりしないでください。保留中の変更保護は、前述の基準を満たしている場合でも、編集率が非常に高い記事には使用しないでください。代わりに、半保護を検討する必要があります。

さらに、管理者は、個々のユーザーをブロックすることが実行可能なオプションではない場合、重大ではあるが一時的な破壊行為または混乱（たとえば、メディアの注目による）の対象となるページに一時的な保留中の変更保護を適用できます。他の形式の保護と同様に、保護の時間枠は問題に比例する必要があります。無期限のPC保護は、深刻な長期的な混乱の場合にのみ使用する必要があります。

半保護と同様に、PC保護は、特定の編集者グループを不利な立場に置くリスクがある本物のコンテンツ紛争では決して使用しないでください。

管理者権限のない編集者は、上記の基準が満たされている場合、ページ保護を要求できます。保留中の変更保護の除去は、任意の管理者の要求、またはにすることができプロテクト解除の要求。

レビューのプロセスは、編集に次のものが含まれていないことを確認するための簡単なチェックとして意図されています。

• 破壊行為
• 生きている人々に関する方針の違反
• 著作権侵害
• その他の明らかに不適切なコンテンツ

レビューアは、他のユーザーの編集を受け入れる能力を付与された十分な経験を積んだユーザーです。レビューアは、ロールバッカーと同様のレベルの信頼を持っています。すべての管理者にはレビュー担当者の権利があります。潜在的なレビュー担当者は、破壊行為を認識し、生きている人々に関するポリシーなどの基本的なコンテンツポリシーに精通し、ウィキペディアの編集にある程度の経験を持っている必要があります。レビュープロセスとレビュー担当者への期待が詳細に記載されているレビューガイドラインを読むことをお勧めします。

レビュー担当者と管理者は、レビューが必要な保留中の編集がある場合は常に、ウォッチリストにピンクのウォッチリストバナーが表示されます。レビュー担当者または管理者が無効にしたい場合は、common.cssに貼り付ける#mw-fr-watchlist-pending-notice {display: none}ことができます。

レビューアによる編集の承認は、編集を承認するものではありません。上記のように、編集で明らかな問題がないかチェックされたことを示しているだけです。

レビューアの権利は、Wikipedia：Requests forpermissionsでの要求に応じて付与されます。管理者にはレビュー担当者の権限を削除する技術的能力がありますが、削除は、ディスカッションからの合意の結果として、または編集者が自分の権限の削除を要求した場合にのみ行う必要があります。レビューアの許可の削除に関する議論は、通常、管理者の掲示板で行う必要があります。正式に削除をリクエストする前に、関係する編集者と話し合ったり、保留中の変更に関するトークページでセカンドオピニオンをリクエストしたりすることをお勧めします。

保留中の変更のレビューは、妥当な制限時間内（最大で数時間）に解決する必要があります。バックログ管理は、コミュニティレベルで調整する必要があります。バックログはSpecial：PendingChangesで表示できます。2013年1月の時点で、編集が2〜3時間以上レビューされないことはめったになく、バックログは頻繁に空になります。

編集履歴では、受け入れられたリビジョンが強調表示され、読みやすさが向上します。さらに、特定の編集が受け入れられた理由を示すために、表示可能なタグが適用されます（「自動的に受け入れられた」/「[ユーザー名]によって受け入れられた」）。2018年9月現在^[更新]、保留中の変更設定が無効になっている場合は常に、特定のページでの過去の変更について、この強調表示は完全に失われます。^[1]保留中の変更を再度有効にすると、強調表示は新しい変更にのみ適用されます。したがって、他の保護が適用される場合は、保留中の変更を有効のままにしておくことをお勧めします。^[2]

確立されたユーザーが未レビューの保留中の変更を含む記事を編集した場合、新しいバージョンは自動的に受け入れられますか？

いいえ。ユーザーがレビュー担当者である場合 （つまり、ユーザーに「レビュー担当者」権限が付与されている場合）、レビューされていない保留中の変更を確認して受け入れるように求められます。ユーザーがレビュー担当者でない場合、編集は「レビュー待ち」としてもマークされます。（レビュー担当者は、保留中の変更の下でページの現在のバージョンを受け入れずに編集を試みることでこれを テストできます。）これの例外は、ユーザーが保留中の編集を最新の受け入れられたリビジョンに戻す場合です。

保留中の変更中の記事に対する複数のIP編集の結果、編集がnullになった場合はどうなり ますか？（たとえば、IPが編集を行った後、別のIPが それを元に戻します。）

それらがすべて単一のIPによって作成された場合、新しいバージョンは自動的に受け入れられます。別のユーザーが編集した場合、新しいバージョンは受け入れられません（潜在的な悪用を防ぐため）。

保留中の変更は どの 種類のページで使用できますか？

当初、保留中の変更は、保護ポリシーの対象となる記事、および プロジェクトスペースのテストページでのみ使用できることがコンセンサスによって決定されました 。その後のコメントの要求により、記事以外の保留中の変更を使用することが許可されていることがわかりました。ただし、ソフトウェアによってメインおよびプロジェクトの名前空間に制限されており、他の名前空間を許可する要求は行われませんでした。トークページを保留中の変更に配置することは技術的に不可能です。

保留中の変更の保護は削除されませんでしたか？

はいといいえ。保留中の変更の保護は2010年に試験的に展開されました。2011年に、保留中の変更の保護は、その展開に関するコンセンサス合意に達するまで、ページを保護するメカニズムとして削除されました。この機能の使用について一連の議論があり、2012年12月1日にサービスが再開されました。それ以降、新規ユーザーと未登録ユーザーの編集に影響する保留中の変更レベル1のみが使用されています。2017年1月の時点で、保留中の変更レベル2を削除するというコンセンサスがあり、その結果、レベル1のみが使用されるようになりました。

ページに保留中の変更保護があるかどうかをどのように判断できますか？

保護されたページは通常、保護のレベルに応じて、上隅に小さな南京錠の記号でマークされます。また、記事のタイトルの横にドロップダウンボックスがあり、保留中の変更がある場合はそれを示します。

以下は、保留中の変更機能に関連する過去のディスカッションと投票のリストです。

• 2009年3月： 最初の投票4対1で最初の裁判を承認
• 2010年5月： いくつかの審理前の問題に関するRFC
• 2010年6月– 2010年8月：保留中の変更トライアル
• 2010年8月： 何らかの形でPCを継続することを支持するストロー投票2対1
• 2010年9月： 暫定使用に関する投票
• 2010年9月– 2011年5月：明確な権限なしに保留中の変更を継続
• 2011年2月– 2011年5月： PC RfC2011最初のPCトライアルを終了しました。
• 2012年3月– 2012年6月： PC RfC 2012は、2012年末までにPCを有効にするためのコンセンサスを確立しました。
  • 2012年9月： WP：PC2012 / RfC 1は、レベル2の保留中の変更を使用するかどうかについて議論しました。
  • 2012年10月： WP：PC2012 / RfC 2は、保留中の変更をいつ適用するか、編集を拒否するための基準、およびバックログを減らすためのさまざまなアイデアについて議論しました。
  • 2012年11月： WP：PC2012 / RfC 3は、保留中の変更機能の展開と使用法について説明しました。
• 2012年12月–：保留中の変更が恒久的に再度有効になります
• 2013年5月： PC RfC 2013は、実装のためのさらなる議論が必要なため、終了しました。レベル2の保留中の変更を使用するかどうかの質問を再開しました。
• 2014年1月： PC RFC 2014は、保留中の変更レベル2を実装する方法についてコンセンサスがあるかどうかを判断するために開かれました。6月にクローズされるまでに、保留中の変更レベル2を使用するコンセンサスはまったくありませんでした。そのようなコンセンサスは発展しますが、それをいつ適用するかについてはいくつかのコンセンサスがあります。
• 2016年10月： DC RFC 2016が開かれ、編集フィルター、ボット、およびORESが、延期された変更を使用してレビューのために疑わしい編集を延期することを許可する必要があるかどうかが決定されました。RfCは完全に合格しました。
• 2016年11月： PC RFC 2016＃1が開かれ、PC2の自動受け入れしきい値を下げることを提案し、使用基準を確立しました。
• 2016年11月： PC RFC 2016＃2が開かれ、すべての記事に保留中の変更を実装する、特定の種類の記事（良い記事、特集記事、重要な記事、生きている人の伝記など）に実装する、自動-特定の基準を満たす人にレビュー担当者の権利を付与し、レビュー用の半自動ツールを作成します。半自動レビューツールを作成するための部分は、コンセンサスを必要としないとしてRfCから撤回され、RfCはその後、残りのすべての提案された変更に対するコンセンサスで雪上閉鎖されました。
• 2017年1月： 対象に関するすべてのRFCがそれを使用するためのコンセンサスを達成できなかった後、保留中の変更レベル2を削除するRFC。
• 2017年11月：延期された変更を実装するための提案は、その技術的な実装に関する作業が不足していたため、休止状態としてマークされました。

• ウィキペディア：フラグ付き保護とパトロールされた改訂、元の試験提案。
• ウィキペディア：時限フラグ付きリビジョン、保留中の変更に時限自動レビューを追加する提案、よりソフトな（より広い）保護ツールとして機能します。
• ウィキペディア：延期された変更、ボットを許可する提案、編集フィルター、および/またはORESが疑わしい編集をレビューのために延期する（元々はウィキペディア：延期された改訂）。
• ウィキペディア：パトロールされた改訂、パッシブレビューシステムのリクエスト、元の提案の一部。
• ウィキペディア：保留中の変更ブロック、保留中の変更保護が従来の保護に対して何であるかをクラシックブロックに対して行うユーザー固有の編集制限の形式の提案。
• ウィキペディア：PC2012、保留中の変更の2012年の実装の概要。
• ウィキペディア：保留中の変更に関する警告、保留中の変更の使用が厳しく制限された理由に関するエッセイ。

インターフェース

• Special：PendingChanges、編集が保留中のページ。
• Special：StablePages、保留中の変更中のページ。
• Special：ValidationStatistics、保留中の変更機能に関連するさまざまな統計。
• Template：Pending Changes backlog、ユーザーページに追加できる現在のバックログの表示。

ログ

• 特別：ログ/安定、保留中の変更を有効または無効にするアクション。
• Special：AdvancedReviewLog、編集をレビューするアクション。