Страница полузащищенная

Википедия: ожидающие изменения

Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Защита ожидающих изменений - это инструмент, используемый для подавления вандализма и некоторых других повторяющихся неприятностей в Википедии, позволяя добросовестному пользователю отправить правку на проверку. Предназначенная для редко редактируемых статей, которые подвергаются большому количеству проблемных правок со стороны новых или незарегистрированных пользователей, защита ожидающих изменений может использоваться в качестве альтернативы полузащите и полной защите, чтобы позволить незарегистрированным и новым пользователям редактировать страницы, сохраняя при этом правки. скрыты для большинства читателей, пока они не будут приняты рецензентом. В Википедии относительно мало статей с таким типом защиты.

Когда страница, находящаяся под защитой ожидающих изменений, редактируется незарегистрированным (также называемым IP) редактором или новым пользователем , это изменение не отображается напрямую для большинства читателей Википедии, пока оно не будет рассмотрено и принято редактором с правом рецензента .

Незавершенные изменения видны в истории страницы, где они помечаются как ожидающие рассмотрения. Последняя принятая ревизия отображается для широкой публики, в то время как зарегистрированные пользователи видят последнюю ревизию страницы со всеми примененными изменениями. Когда редакторы, не являющиеся рецензентами, вносят изменения в статью с непроверенными ожидающими изменениями, их правки также помечаются как ожидающие и не видны большинству читателей.

И пользователи, вошедшие в систему, и незарегистрированные пользователи, которые щелкают вкладку «Редактировать эту страницу», редактируют последнюю версию как обычно. Если есть ожидающие рассмотрения изменения, рядом с заголовком статьи появится раскрывающийся список, указывающий на ожидающие изменения.

Незавершенные изменения могут быть использованы для защиты статей от постоянного вандализма, нарушений политики биографий живых людей и нарушений авторских прав.

Применение защиты отложенных изменений

Администраторы могут применять защиту отложенных изменений к страницам, которые подвергаются серьезному и постоянному вандализму , нарушениям политики биографий живых людей или вставке контента, нарушающего авторские права. Защита ожидающих изменений не должна использоваться в качестве превентивной меры против нарушений, которые еще не произошли, а также не должна использоваться для предоставления привилегий зарегистрированным пользователям над незарегистрированными пользователями в спорах о содержании. Защиту от ожидающих изменений не следует использовать для статей с очень высоким процентом редактирования, даже если они соответствуют вышеупомянутым критериям. Вместо этого следует рассмотреть возможность полузащиты.

Кроме того, администраторы могут применять временную защиту от ожидающих изменений на страницах, которые подвержены значительному, но временному вандализму или нарушению работы (например, из-за внимания СМИ), когда блокировка отдельных пользователей не является возможным вариантом. Как и в случае с другими формами защиты, сроки защиты должны быть пропорциональны проблеме. Бесконечную защиту ПК следует использовать только в случае серьезных долговременных сбоев.

Как и полузащита, защита ПК никогда не должна использоваться в спорах о подлинном содержании, когда существует риск поставить определенную группу редакторов в невыгодное положение.

Редакторы без прав администратора могут запросить защиту страницы при соблюдении вышеуказанных критериев. Удаление отложенных изменений защиты может быть запрошено у любого администратора или при запросах на снятие защиты .

Просмотр изменений, ожидающих рассмотрения

Процесс рецензирования предназначен для быстрой проверки, чтобы убедиться, что правки не содержат:

  • вандализм
  • нарушения политики в отношении живых людей
  • нарушение авторских прав
  • другой явно неприемлемый контент

Рецензенты - это достаточно опытные пользователи, которым предоставлена ​​возможность принимать правки других пользователей. Рецензенты имеют такой же уровень доверия, как и те, кто выполняет откат ; все администраторы имеют право рецензента. Потенциальные рецензенты должны распознавать вандализм, быть знакомы с основными политиками в отношении контента, такими как политика в отношении живых людей, и иметь достаточный опыт редактирования Википедии. Рекомендуется прочитать руководство по рецензированию , в котором подробно описаны процесс рецензирования и ожидания рецензента.

Рецензенты и администраторы будут видеть розовый баннер списка наблюдения в своих списках наблюдения всякий раз, когда есть незавершенные изменения, требующие проверки. Если рецензент или администратор желают отключить его, они могут вставить его #mw-fr-watchlist-pending-notice {display: none}в свой common.css .

Принятие редактирования рецензентом не означает его одобрение. Это просто указывает на то, что редактирование было проверено на наличие очевидных проблем, перечисленных выше.

Права рецензента предоставляются по запросу в Википедии: Запросы разрешений . Хотя любой администратор имеет техническую возможность удалить разрешение рецензента, удаление должно происходить только в результате консенсуса в ходе обсуждения или когда редактор запрашивает удаление своего разрешения. Обсуждение удаления разрешения рецензента обычно должно происходить на доске объявлений администратора . Перед официальным запросом на удаление рекомендуется обсудить с задействованным редактором и / или запросить второе мнение на странице обсуждения ожидающих изменений .

Проверка ожидающих изменений должна выполняться в разумные сроки (максимум несколько часов). Управление невыполненными работами должно координироваться на уровне сообщества. Бэклог можно просмотреть на странице Special: PendingChanges . По состоянию на январь 2013 года правки редко остаются без внимания более двух-трех часов, а список невыполненных работ часто пуст.

В ожидании изменений добавлено выделение, которое теряется при отключении

В истории изменений принятые исправления выделяются, что улучшает читаемость. Кроме того, применяются видимые теги, указывающие, почему были приняты определенные изменения («принято автоматически» / «принято [Имя пользователя]»). По состоянию на сентябрь 2018 года это выделение по-прежнему навсегда теряется для прошлых изменений на данной странице, если параметр ожидающих изменений отключен. [1] Когда ожидающие изменения снова будут включены, выделение будет применено только к более новым изменениям. Таким образом, рекомендуется оставить отложенные изменения включенными при применении других средств защиты. [2]

Эффект различных уровней защиты

Взаимодействие групп пользователей Википедии и уровней защиты страниц
 Незарегистрированный или недавно зарегистрированныйПодтверждено автоматически , подтвержденоРасширенный подтвержденРедактор шаблоновАдминПодходит для
( См. Также : Википедия: Политика защиты )
Нет защитынормальное редактированиеЭто уровень защиты по умолчанию, используемый для подавляющего большинства страниц.
Защита отложенных измененийвсе пользователи могут редактировать. Однако после того, как незарегистрированный или новый редактор внесет правку, это редактирование и любые последующие правки, сделанные кем-либо , останутся скрытыми от «читателей» (пользователей, не вошедших в систему) до тех пор, пока правка, сделанная незарегистрированным или новым редактором, не будет проверена рецензентом ожидающих изменений. или админ .Нечасто редактируемые страницы с высоким уровнем вандализма, нарушений BLP , противодействия редактированию или других нарушений со стороны незарегистрированных и новых пользователей
Полузащитане может редактироватьнормальное редактированиеСтраницы с высоким уровнем прерывания работы незарегистрированными и новыми пользователями; несколько хорошо заметных шаблонов и модулей
Продлен- подтвержденный прот.не может редактироватьнормальное редактирование *Конкретные тематические области, авторизованные Arbcom ; страницы, подверженные постоянным сбоям, которые не удалось остановить с помощью полузащиты
Прототип шаблона.не может редактироватьнормальное редактированиеШаблоны и модули высокого риска ; также некоторые страницы с высоким уровнем риска за пределами шаблона
Полная защитане может редактироватьнормальное редактированиеСтатьи с постоянными сбоями из расширенных подтвержденных аккаунтов; критические шаблоны и модули
* Редактор шаблонов также должен быть расширен с подтверждением, чтобы редактировать с помощью расширенной подтвержденной защиты, но на практике это всегда так.

Другие способы защиты:

  • Защита интерфейса
  • Создать защиту
  • Защита от перемещения
  • Защита загрузки
  • Офисная охрана
  • Каскадная защита


Часто задаваемые вопросы

Если уже имеющийся пользователь редактирует статью с непроверенными ожидающими изменениями, принимается ли новая версия автоматически?
Нет. Если пользователь является рецензентом (т. Е. Ему было предоставлено разрешение «рецензент»), ему будет предложено просмотреть и принять любые непроверенные ожидающие изменения. Если пользователь не является рецензентом, правка также будет помечена как «ожидающая проверки». (Рецензенты могут проверить это , отменив принятие текущей версии страницы при ожидающих изменениях, а затем попытаясь отредактировать.) Исключением является случай, когда пользователь откатывает отложенное изменение до последней принятой ревизии: в этом случае откат автоматически принимается.
Что произойдет, если несколько IP-правок статьи с ожидающими изменениями приведут к нулевому изменению ? (Например, IP-адрес вносит изменения, затем другой IP-адрес отменяет его.)
Если все они были сделаны с одного IP, новая версия принимается автоматически. Если редактировали другие пользователи, новая версия не принимается (во избежание возможных злоупотреблений).
На каких типах страниц можно использовать ожидающие изменения?
Сначала было решено, что ожидающие изменения могут использоваться только в статьях, подпадающих под действие политики защиты , и на тестовых страницах в пространстве проекта. В более позднем запросе о комментариях было установлено, что допустимо использовать ожидающие изменения помимо статей; однако оно ограничено программным обеспечением основным пространством имен и пространством имен проекта, и не было сделано никаких запросов на разрешение других пространств имен. Размещение страниц обсуждения на ожидающих изменениях технически невозможно.
Не сбрасывалась ли защита отложенных изменений?
И да и нет. Защита отложенных изменений была развернута на пробной основе в 2010 году. В 2011 году защита отложенных изменений была исключена как механизм защиты страниц, пока не было достигнуто консенсусное соглашение о ее развертывании. Была проведена серия обсуждений использования этой функции, и 1 декабря 2012 года она была снова введена в эксплуатацию. С тех пор используются только незавершенные изменения уровня 1, влияющие на правки новых и незарегистрированных пользователей. По состоянию на январь 2017 года был достигнут консенсус об отказе от отложенных изменений уровня 2, и в результате теперь используется только уровень 1.
Как узнать, есть ли на странице защита от отложенных изменений?
Защищенные страницы обычно помечаются маленьким символом замка в верхнем углу в зависимости от уровня защиты. Кроме того, рядом с заголовком статьи будет раскрывающийся список, указывающий на ожидающие изменения, если таковые имеются.

График

Ярлык
  • WP: PCRFC

Ниже приведен список прошлых обсуждений и опросов, касающихся функции «Ожидающие изменения»:

  • Март 2009: первый опрос 4: 1, одобряющий первоначальное исследование.
  • Май 2010: RFC по некоторым досудебным вопросам
  • Июнь 2010 г. - август 2010 г.: пробная версия "Ожидающие изменения"
  • Август 2010: Straw опрос 2: 1 в пользу продолжения ПК в той или иной форме.
  • Сентябрь 2010: Опрос Straw о временном использовании
  • Сентябрь 2010 г. - май 2011 г.: продолжение ожидающих изменений без четкого мандата.
  • Февраль 2011 г. - май 2011 г.: PC RfC 2011 Завершена первоначальная пробная версия ПК.
  • Март 2012 - июнь 2012: PC RfC 2012 достиг консенсуса, чтобы включить PC до конца 2012 года.
    • Сентябрь 2012: WP: PC2012 / RfC 1 обсудили, следует ли использовать ожидающие изменения Уровня 2.
    • Октябрь 2012: WP: PC2012 / RfC 2 обсудили, когда применять ожидающие изменения, критерии отклонения изменений и различные идеи по сокращению отставания.
    • Ноябрь 2012: WP: PC2012 / RfC 3 обсудили развертывание и использование функции ожидающих изменений.
  • Декабрь 2012 г .: Незавершенные изменения снова включены на постоянной основе.
  • Май 2013: PC RfC 2013 закрыт, так как требует дальнейшего обсуждения для внедрения. Это вновь подняло вопрос о том, следует ли использовать ожидающие изменения Уровня 2.
  • Январь 2014: PC RFC 2014 был открыт для определения, есть ли консенсус в отношении того, как реализовать ожидающие изменения уровня 2. К моменту закрытия в июне уже не было консенсуса относительно использования ожидающих изменений уровня 2, но если и когда такой консенсус действительно развивается, есть определенный консенсус относительно того, когда его применять.
  • Октябрь 2016: Открыт DC RFC 2016, чтобы определить, следует ли разрешить фильтру редактирования, ботам и ORES откладывать подозрительные изменения на проверку с помощью отложенных изменений . РФК принят полностью.
  • Ноябрь 2016: PC RFC 2016 # 1 был открыт, предлагая снизить порог автоматического принятия для PC2 и установить критерии использования.
  • Ноябрь 2016: PC RFC 2016 # 2 был открыт, чтобы предложить несколько вещей, включая реализацию ожидающих изменений для всех статей, реализацию его для определенных типов статей (включая хорошие статьи , избранные статьи , важные статьи и статьи с биографиями живых людей ), авто- предоставление права рецензента для тех, кто соответствует определенным критериям, и создание полуавтоматического инструмента для рецензирования. Часть, касающаяся создания полуавтоматического инструмента проверки, была отозвана из RfC как не требующая консенсуса, а RfC позже был закрыт с консенсусом против всех оставшихся предложенных изменений.
  • Январь 2017: RFC для удаления ожидающих изменений уровня 2 после того, как все RFC по этому вопросу не смогли достичь консенсуса по его использованию.
  • Ноябрь 2017: предложение по реализации отложенных изменений был отмечен как в состоянии покоя, после отсутствия работы по его технической реализации.

Смотрите также

  • Википедия: помеченная защита и патрулированные исправления , первоначальное пробное предложение.
  • Википедия: исправления , помеченные по времени , предложение добавить автоматический просмотр по времени к ожидающим изменениям, чтобы действовать как более мягкий (более широкий) инструмент защиты.
  • Википедия: отложенные изменения , предложение о разрешении ботов , фильтр редактирования и / или ORES, чтобы отложить подозрительные изменения для проверки (изначально Википедия: отложенные изменения ).
  • Википедия: патрулируемые изменения , запрос на систему пассивной проверки, часть первоначального предложения.
  • Википедия: Блоки ожидающих изменений , предложение формы ограничения редактирования для конкретного пользователя, то есть классического блока, что и защита ожидающих изменений для классической защиты.
  • Википедия: PC2012 , обзор реализации ожидающих изменений в 2012 году.
  • Википедия: Предостережения об ожидающих изменениях , эссе о том, почему использование ожидающих изменений было строго ограничено.

Интерфейс

  • Special: PendingChanges , страницы с ожидающими правками.
  • Special: StablePages , страницы с ожидающими изменениями.
  • Special: ValidationStatistics , различная статистика, относящаяся к функции ожидающих изменений.
  • Шаблон: Журнал ожидающих изменений , отображение текущего бэклога, которое может быть добавлено на пользовательские страницы.

Журналы

  • Special: журнал / стабильный , действия по включению или отключению отложенных изменений.
  • Special: AdvancedReviewLog , действия по проверке правок.

Сноски

  1. ^ "⚓ T189422 Отключение отложенных изменений удаляет визуальное выделение и маркировку возвратов и подтверждений" . phabricator.wikimedia.org . Проверено 26 апреля 2019 .
  2. ^ По состоянию на сентябрь 2018 года нет защиты слабее, чем уровень ожидающих изменений 1 (ПК1), поэтому ПК1 не будет мешать, когда включены другие защиты.