- Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать на соответствующей странице обсуждения. Никаких дальнейших изменений в это обсуждение вносить не следует.
- Задний план
- Опрос, одобряющий испытание помеченной защиты и патрулируемых исправлений , конкретной реализации помеченных исправлений, был закрыт 1 апреля 2009 года.
- Фонд Викимедиа создал команду для развертывания пробной версии, создан тестовый сайт для проверки конфигурации, он используется с сентября 2009 года.
- Ситуация
- Команда, отвечающая за развертывание пробной версии, объявила, что они находятся на этапе предварительного развертывания. Внедрение ожидается в ближайшие несколько недель.
- В испытании будет участвовать только отмеченная защита, патрулируемые доработки еще не разработаны.
- Запрошенная конфигурация, помеченная защита с группой пользователей-рецензентов и возможность деактивировать автоматический просмотр, в настоящее время включена на сайте тестирования и достаточно стабильна.
- Некоторое время команда хотела развернуть для пробной версии версию без группы пользователей-рецензентов и предоставить автоматически подтвержденным пользователям права на просмотр, в то время как сообщество неоднократно отвергало эту возможность. [1] [2] [3] [4] Позже была возвращена исходная реализация.
Закрытие
Перемещено в Обсуждение Википедии: Ожидающие изменения / Пробная версия . Кенарий ( разговор ) 22:25, 13 июня 2010 (UTC)
Использование помеченной защиты
В результате консенсуса, сформированного для этого испытания, было решено, что политика использования помеченной защиты такая же, как и для использования полузащиты; а для отмеченной защиты без автопросмотра - то же, что и для полной защиты. Однако не было решено, в каких случаях администратор должен использовать полузащиту вместо защиты с флажками или наоборот, или следует ли использовать группы управления и тому подобное.
- Комментарии
(разговор перешел на обсуждение в Википедии: Ожидающие изменения / Очередь - RobLa ( обсуждение ) 21:55, 10 июня 2010 г. (UTC))
Обзор
- Комментарии
Я думаю, нам нужно место, где рецензенты могут сообщать об изменениях, которые они не уверены принимать или нет, и где это можно обсуждать, своего рода доска объявлений рецензентов. Нам также нужно подготовить руководство, есть руководство Wikipedia: Reviewing, которое мы, вероятно, должны объединить в Wikipedia: ожидающие изменения . Кенарий ( разговор ) 02:24, 11 июня 2010 (UTC)
Реклама
О пробной версии нужно будет сообщить редакторам. Уведомление о сайте кажется неадекватным, поскольку мы должны сосредоточиться на редакторах, а уведомления о списке наблюдения недостаточно, потому что значительное число редакторов не часто используют список наблюдения. Было предложено использовать уведомление, которое отображается в режиме редактирования и на страницах обсуждения, возможно, также на страницах проекта и которое может быть отклонено. Но реализации этого нет.
- Комментарии
Что-то сделано в этом направлении на техническом уровне? Т.е. создано новое сообщение или можно аккуратно скрыть уведомление о сайте в пространствах имен main / portal / category / file на время уведомления о пробной версии? Кенарий ( разговор ) 13:21, 7 июня 2010 (UTC)
- Вероятно, уже слишком поздно реализовывать сообщение типа уведомления для страниц редактирования (насколько я знаю). Однако на этих страницах все еще есть стандартное сообщение, которое, возможно, можно сделать более заметным в начале испытания: http://flaggedrevs.labs.wikimedia.org/wiki/MediaWiki:Revreview-locked . На страницах обсуждения кажется, что достаточно иметь стандартный шаблон. - RobLa ( разговор ) 05:12, 8 июня 2010 г. (UTC)
- Цель состоит в том, чтобы рассказать об испытании как можно большему количеству редакторов, чтобы они могли произвести свое впечатление и помочь прийти к консенсусу относительно продолжения или прекращения внедрения в конце испытания. Нам абсолютно необходимо широко рекламировать, чтобы сформированный консенсус был репрезентативным для редакционного сообщества в целом. Это отличается от интерфейсных сообщений, используемых в статьях, где эта функция включена. Я предупреждал об этой проблеме несколько раз с 2009 года. Кенарий ( разговор ) 13:13, 9 июня 2010 г. (UTC)
- Чтобы прояснить ситуацию, я думаю, что мы должны использовать уведомление о сайте для пользователей, вошедших в систему, но анонимные редакторы также должны иметь возможность знать о пробной версии, поэтому нам нужно найти что-то, чтобы сообщить им об этом. Кенарий ( разговор ) 13:24, 9 июня 2010 (UTC)
- Посмотрим, как все будет выглядеть после первой недели. Я подозреваю, что это привлечет все внимание, которое мы хотим, но мы постараемся привлечь больше интереса, если окажется, что через неделю мы не получим достаточно. Одним из способов сделать это может быть что-то с помощью уведомления об изменении в основном пространстве имен , но я недостаточно знаком с тем, как это работает, чтобы точно знать, подходит ли это инструмент для работы. - RobLa ( разговор ) 04:34, 13 июня 2010 г. (UTC)
- Я спросил в ВПТ . Я считаю важным узнать мнение незарегистрированных пользователей об этом испытании. Кенарий ( разговор ) 04:44, 13 июня 2010 (UTC)
- Посмотрим, как все будет выглядеть после первой недели. Я подозреваю, что это привлечет все внимание, которое мы хотим, но мы постараемся привлечь больше интереса, если окажется, что через неделю мы не получим достаточно. Одним из способов сделать это может быть что-то с помощью уведомления об изменении в основном пространстве имен , но я недостаточно знаком с тем, как это работает, чтобы точно знать, подходит ли это инструмент для работы. - RobLa ( разговор ) 04:34, 13 июня 2010 г. (UTC)
Предоставление прав рецензента
Чтобы убедиться, что у нас достаточно большой пул рецензентов.
- Комментарии
- Я упоминал о возможности добавить группу рецензентов за несколько дней до начала пробной версии (без прав), чтобы у нас было время сделать некоторую гранту до ее начала. Каково ваше мнение по этому поводу (сейчас немного поздно, но все же возможно)?
- Я запросил отчет по базе данных здесь, чтобы мы могли немедленно начать предоставлять права рецензента в среднем масштабе, не дожидаясь запросов от людей. DBR находится в Википедии: Отчеты по базам данных / Кандидаты в потенциальные рецензенты (в настоящее время более одного года, поэтому их нельзя использовать).
- Мы должны создать стандартный шаблон, объясняющий право рецензента, который администраторы предоставляют пользователям, которым они предоставили право (или вариант). Мы можем использовать два шаблона или, альтернативно, параметр, чтобы различать, когда это запрашивается пользователем, и когда администратор проявил инициативу, чтобы предоставить право. Кенарий ( разговор ) 15:07, 9 июня 2010 (UTC)
- Согласен, даже несмотря на то, что мы начнем с малого, я думаю, было бы очень полезно начать раздавать флаг до реализации, чтобы у нас был небольшой старт (или, по крайней мере, не начинать за милю от начала). линия). Джеймс ( T C ) 21:55, 10 июня 2010 г. (UTC)
- Я запросил это в Bugzilla как ошибку 23922 . Извините за опоздание. - RobLa ( разговор ) 23:07, 11 июня 2010 г. (UTC)
- Согласен, даже несмотря на то, что мы начнем с малого, я думаю, было бы очень полезно начать раздавать флаг до реализации, чтобы у нас был небольшой старт (или, по крайней мере, не начинать за милю от начала). линия). Джеймс ( T C ) 21:55, 10 июня 2010 г. (UTC)
Я запустил Template: Reviewer-notice . Кенарий ( разговор ) 01:31, 11 июня 2010 (UTC)
К вашему сведению, первые отчеты по базам данных были созданы в Википедии: отчеты по базам данных / потенциальные рецензенты , см. Также AN . Я не уверен, следует ли нам оставлять пояснительное сообщение для пользователей, которым предоставлены права, или этого достаточно. Кенарий ( разговор ) 03:09, 12 июня 2010 (UTC)
Примечание : теперь существует группа «Рецензент», поэтому администраторы могут начать предоставлять права рецензента. В настоящее время эта группа не покупает вам ничего, чего вы еще не получили с автоподтверждением, но это изменится, когда мы включим ожидающие изменения. - RobLa ( разговор ) 17:10, 12 июня 2010 (UTC)
- Фактически, он также предоставляет автопатруль, о чем здесь говорится . Кенарий ( разговор ) 18:06, 12 июня 2010 (UTC)
Удаление прав рецензента
Должны ли мы принять для лишения прав рецензента иной процесс, нежели просто усмотрение администратора? Это обеспечит защиту от необоснованных удалений, и в любом случае удаления должно быть не так много, это может произойти, когда рецензент намеренно и, несмотря на предупреждения, рассматривает явный вандализм или нарушения BLP. Возможны следующие варианты: ограничение возможности удаления бюрократами или стюардами, требование использовать процесс с обсуждением, закрытым невиновным администратором, бюрократом или оставленным на усмотрение ArbCom. Кенарий ( разговор ) 03:18, 12 июня 2010 (UTC)
- Хорошие моменты. Как минимум, процесс лишения прав должен быть и должен рассматриваться как рациональный, справедливый и прозрачный. Произвольное предоставление или удаление прав и даже видимость предвзятости или фаворитизма нанесут ущерб репутации всей системы. Доктор К. λogos πraxis 03:30, 12 июня 2010 г. (UTC)
- Зачем его когда-либо снимать, если кто-то просто не хочет этого? Если они совершают вандализм / грубые нарушения BLP, их следует заблокировать, а не просто забирать игрушки. - B ( разговорное ) 03:46, 12 июня 2010 г. (UTC)
- Разумный вопрос, но я могу представить себе случай, похожий на удаление отката, во время которого редактор делает спорное редактирование, а затем администратор лишает их права по той или иной причине. Доктор К. λogos πraxis 03:51, 12 июня 2010 г. (UTC)
- Но эта функция не должна использоваться для редакционного контроля - она должна использоваться для контроля вандализма / BLP. - B ( разговорное ) 04:08, 12 июня 2010 г. (UTC)
- То же самое и откат, но откат исторически был удален для пользователей. Доктор К. λogos πraxis 04:14 , 12 июня 2010 г. (UTC)
- Например, рецензент удаляет правку, не являющуюся явным вандализмом. Кто-то не согласен с удалением и связывается с администратором. Администратор связывается с редактором, который сделал удаление, они вступают в спор, редактор лишает их прав рецензента. Доктор К. λogos πraxis 04:20, 12 июня 2010 г. (UTC)
- ... таким образом убирается откат. Права рецензента не должны быть лишены за то, что не одобрили добросовестную правку - есть множество причин, по которым нельзя оставлять добросовестную правку. Тем не менее, их следует удалить как можно скорее после того, как они будут использоваться для продвижения любого вида POV, особенно для статьи, защищенной L2. {{ Соня | пинг | enlist }} 04:44, 12 июня 2010 г. (UTC)
- Спасибо, что предоставили еще один пример того, как можно отменить это право. Я добавляю, что, поскольку точка зрения трудно определить, иногда кажется, что это право легче устранить, чем я мог подумать, и в этом заключается проблема. Доктор К. λogos πraxis 04:55, 12 июня 2010 г. (UTC)
- Хорошо ... Думаю, я запутал рецензента и авторевьюера. Это имеет смысл. - B ( разговор ) 05:23, 12 июня 2010 г. (UTC)
- Да. Разные типы рецензентов и, что еще хуже, уровни рецензирования. Об уровнях L1 и L2 я слышал совсем недавно. Понятия не имею, что это такое. Я должен понять эти концепции, как только смогу. Доктор К. λogos πraxis 05:39, 12 июня 2010 г. (UTC)
- Авторевьюер не имеет отношения к делу, я предлагал переименовать его здесь . Я не вижу много способов неправильного / злоупотребления правами на рецензирование: рецензент мог бы `` отменить '' ревизию, ранее принятую рецензентом без каких-либо оснований для этого, но он добавил бы правку обратно в очередь ожидающих изменений для каждый рецензент должен видеть, поэтому было бы разумнее просто отменить правку, а не злоупотреблять правом как таковым; другой случай неправильного / злоупотребления - это когда рецензент принимает очевидный вандализм или нарушение BLP или другие явно несоответствующие правки. Я не думаю, что администратор должен удалять рецензента самостоятельно, по крайней мере, без запуска ANI. И мы также могли бы создать конкретную страницу, на которой размещаются запросы на удаление, которые также могут включать откат, авторевьюер. В качестве меры предосторожности мы можем ограничить возможность удаления прав на просмотр для подгруппы администраторов. Может быть, бюрократы - не лучший выбор, можно было бы использовать функционеров: надзирателей и проверяющих. Кенарий ( разговор ) 13:11, 12 июня 2010 (UTC)
- Спасибо за разъяснения Autoreviewer, хотя я знал об этом. Что касается привлечения надзирателей и проверяющих к лишению прав, это шаг в правильном направлении, но я все еще не понимаю, почему все автоподтвержденные пользователи с хорошей репутацией не попали автоматически в эти новые группы рецензентов, поскольку, по сути, существующие пользователи собираются теряют некоторые из имеющихся у них возможностей редактирования в новом режиме. Я также не совсем понимаю, почему это новое право рецензента должно быть отменяемым. Доктор К. λogos πraxis 22:45, 12 июня 2010 г. (UTC)
- Мы планируем предоставить права автоматически подтвержденным пользователям с хорошей репутацией, но группа рецензентов только что создана, и это долго, чтобы предоставить ее нескольким тысячам пользователей, есть отчеты из базы данных, которые мы можем использовать. Маловероятно, чтобы опытные пользователи «злоупотребляли» правом, см. Wikipedia_talk: Обзор ожидающих изменений # Eyeball_request, чтобы узнать, как это могло быть. Но это возможно, поэтому мы должны принять это во внимание, хотя это должно быть настолько редко (за исключением случаев, когда право было предоставлено слишком легко), что нет проблем с ограничением удаления CU / OS, и это делается после обсуждения . Кенарий ( разговор ) 04:18, 13 июня 2010 (UTC)
- Спасибо за разъяснения Autoreviewer, хотя я знал об этом. Что касается привлечения надзирателей и проверяющих к лишению прав, это шаг в правильном направлении, но я все еще не понимаю, почему все автоподтвержденные пользователи с хорошей репутацией не попали автоматически в эти новые группы рецензентов, поскольку, по сути, существующие пользователи собираются теряют некоторые из имеющихся у них возможностей редактирования в новом режиме. Я также не совсем понимаю, почему это новое право рецензента должно быть отменяемым. Доктор К. λogos πraxis 22:45, 12 июня 2010 г. (UTC)
- Авторевьюер не имеет отношения к делу, я предлагал переименовать его здесь . Я не вижу много способов неправильного / злоупотребления правами на рецензирование: рецензент мог бы `` отменить '' ревизию, ранее принятую рецензентом без каких-либо оснований для этого, но он добавил бы правку обратно в очередь ожидающих изменений для каждый рецензент должен видеть, поэтому было бы разумнее просто отменить правку, а не злоупотреблять правом как таковым; другой случай неправильного / злоупотребления - это когда рецензент принимает очевидный вандализм или нарушение BLP или другие явно несоответствующие правки. Я не думаю, что администратор должен удалять рецензента самостоятельно, по крайней мере, без запуска ANI. И мы также могли бы создать конкретную страницу, на которой размещаются запросы на удаление, которые также могут включать откат, авторевьюер. В качестве меры предосторожности мы можем ограничить возможность удаления прав на просмотр для подгруппы администраторов. Может быть, бюрократы - не лучший выбор, можно было бы использовать функционеров: надзирателей и проверяющих. Кенарий ( разговор ) 13:11, 12 июня 2010 (UTC)
- Да. Разные типы рецензентов и, что еще хуже, уровни рецензирования. Об уровнях L1 и L2 я слышал совсем недавно. Понятия не имею, что это такое. Я должен понять эти концепции, как только смогу. Доктор К. λogos πraxis 05:39, 12 июня 2010 г. (UTC)
- Хорошо ... Думаю, я запутал рецензента и авторевьюера. Это имеет смысл. - B ( разговор ) 05:23, 12 июня 2010 г. (UTC)
- Спасибо, что предоставили еще один пример того, как можно отменить это право. Я добавляю, что, поскольку точка зрения трудно определить, иногда кажется, что это право легче устранить, чем я мог подумать, и в этом заключается проблема. Доктор К. λogos πraxis 04:55, 12 июня 2010 г. (UTC)
- ... таким образом убирается откат. Права рецензента не должны быть лишены за то, что не одобрили добросовестную правку - есть множество причин, по которым нельзя оставлять добросовестную правку. Тем не менее, их следует удалить как можно скорее после того, как они будут использоваться для продвижения любого вида POV, особенно для статьи, защищенной L2. {{ Соня | пинг | enlist }} 04:44, 12 июня 2010 г. (UTC)
- Но эта функция не должна использоваться для редакционного контроля - она должна использоваться для контроля вандализма / BLP. - B ( разговорное ) 04:08, 12 июня 2010 г. (UTC)
- Разумный вопрос, но я могу представить себе случай, похожий на удаление отката, во время которого редактор делает спорное редактирование, а затем администратор лишает их права по той или иной причине. Доктор К. λogos πraxis 03:51, 12 июня 2010 г. (UTC)
- Спасибо. Нам понадобится консенсус для ограничения удаления CU / OS. Кенарий ( разговор ) 15:34, 13 июня 2010 (UTC)
- Я бы возражал против ограничения удаления CU / OS по нескольким причинам:
- Это выходит за рамки того, для чего предназначены группы CU / OS; нет никаких проблем с приватностью. Если это должно быть ограничено группой, не являющейся администратором, это должны быть бюрократы, поскольку их роль, по крайней мере, связана с работой с правами пользователей.
- Если он предоставляется по усмотрению администратора, я не вижу причин, по которым его нельзя было бы удалить по усмотрению администратора. Тот факт, что это не нужно делать часто, не является поводом для ограничения. Злоупотребление или неправильное использование этого, похоже, не намного сложнее обнаружить, чем злоупотребление или неправильное использование отката.
- Администраторы (или на самом деле любой пользователь) не должны иметь возможности делать то, что они не могут отменить.
- Требование от чиновника лишить права прав становится гораздо более серьезным делом, чем должно быть.
- - Г-н З- ман, 17:05, 13 июня 2010 г. (UTC)
- Это что-то вроде отвлекающего маневра. Bureacrats могут «повысить» пользователя до администратора, но они не могут «понизить» администратора до обычного редактора, поэтому есть прецедент, когда это новое право было лишено права на доступ к администраторам. Есть очень веские доказательства того, что откат нередко удаляется администраторами по прихоти, и поэтому нет оснований предполагать, что это новое право не будет таким же хорошим. Malleus
Fatuorum 17:40, 13 июня 2010 г. (UTC)
- Я согласен с тем, что нам нужно больше, а не меньше гарантий в отношении удаления, как я объяснил выше. Я считаю подход Cenarium лучшим. Доктор К. λogos πraxis 18:02, 13 июня 2010 г. (UTC)
- Однако есть серьезный недостаток: если люди видят, что удалить право слишком сложно, они захотят, чтобы его предоставили более высокие стандарты; и очень важно предоставить право достаточному количеству рецензентов. Бюрократы не хотят брать на себя новые обязанности, и это может «политизировать» их функции, то же самое можно сказать и о CU / OS. Лично я считаю, что этого должно быть достаточно, чтобы потребовать общего согласия для удаления. Кенарий ( разговор ) 18:34, 13 июня 2010 (UTC)
- Я согласен с тем, что нам нужно больше, а не меньше гарантий в отношении удаления, как я объяснил выше. Я считаю подход Cenarium лучшим. Доктор К. λogos πraxis 18:02, 13 июня 2010 г. (UTC)
- Это что-то вроде отвлекающего маневра. Bureacrats могут «повысить» пользователя до администратора, но они не могут «понизить» администратора до обычного редактора, поэтому есть прецедент, когда это новое право было лишено права на доступ к администраторам. Есть очень веские доказательства того, что откат нередко удаляется администраторами по прихоти, и поэтому нет оснований предполагать, что это новое право не будет таким же хорошим. Malleus
Fatuorum 17:40, 13 июня 2010 г. (UTC)
Хорошо, давай обсудим здесь, пожалуйста. Кенарий ( разговор ) 20:44, 13 июня 2010 (UTC)
Уровень защиты 2
Перемещено в Википедию: Запросы на комментарии / Пробная версия ожидающих изменений . Кенарий ( разговор ) 22:23, 13 июня 2010 (UTC)
Группа авторевьюеров
Autoreviewer группа пользователей, первоначально названный autopatroller, был создан в 2009 году, пользователи с этим разрешением являются autopatrolled. Было предложено, чтобы мы использовали эту группу с помеченными ревизиями для пользователей, которые проверяются автоматически, но в этой реализации все автоматически подтвержденные пользователи и помеченная защита не связана с патрулированием новых страниц. Поскольку это может вызвать путаницу, было предложено переименовать его в автопатроллер. Хотя это может конфликтовать с патрулированными версиями.
- Комментарии
Предлагаю переименовать здесь . Кенарий ( разговор ) 04:19, 13 июня 2010 (UTC)
Имя
См . Обсуждение в Википедии: Защита с пометкой и патрулируемые изменения / Терминология .
- Комментарии
Вероятно, нецелесообразно снова менять имя на этом этапе перед запуском. Однако есть и другие второстепенные термины, которые все еще потенциально обсуждаются в Википедии: Защита с пометкой и патрулируемые версии - RobLa ( обсуждение ) 05:05, 8 июня 2010 г. (UTC)
- Я думаю, что нынешнее название, появившееся после долгих обсуждений, уходит от «помеченного» багажа, который, по-видимому, возник, и я, конечно, не поддерживаю еще одно изменение на данном этапе. Ресурсы разработки следует использовать для других целей. ++ Lar : t / c 10:34, 8 июня 2010 г. (UTC)
Группа рецензентов
Отмеченная защита без группы пользователей проверяющего была исходной версией помеченной защиты, обсуждаемой здесь , консенсуса не было достигнуто, и она была окончательно отклонена в пользу новой версии. Автопродвижение рецензентов и, тем более, предоставление прав на рецензирование всем автоподтвержденным пользователям было отклонено в лекции Википедии: Рецензенты # Новое обсуждение и опрос: критерии рецензента и в предыдущем опросе.
Причины использования группы пользователей рецензента
- высокий риск для добросовестных пользователей с автоподтверждением быть наказанными за плохие отзывы из-за неопытности (а не злого умысла)
- очень высокий риск для злоумышленников скомпрометировать систему с плохими отзывами
- недоверие к системе рецензирования
- нет возможности защиты от sockpuppeters и серьезных сбоев, как обеспечивает промежуточный отмеченный уровень защиты, необходимо использовать полную защиту, как сейчас
- считает несостоятельным главный разработчик FlaggedRevs Аарон Шульц [5]
- необходимо дважды проверять отзывы, что, в свою очередь, может повлиять на эффективность обработки правок
Причины против использования группы пользователей-рецензентов
- менее сложный
- больше пользователей с возможностью просмотра - меньше вероятность отставания
Обсуждение
- Я не уверен, что это уменьшит отставание, так как потребуется перепроверять отзывы и разбираться с плохими отзывами. Мы планировали либеральное предоставление группы рецензентов, поэтому большинству пользователей, заинтересованных в рецензировании, вероятно, в любом случае будут предоставлены права. С отчетами базы данных, идентифицирующими кандидатов, вероятно, достаточно опытных для получения права, вряд ли будет нехватка в рецензентах. Кроме того, изменения, внесенные автоматически подтвержденными пользователями, автоматически проверяются при просмотре предыдущей версии (кроме случаев, когда она специально отключена для работы с носками / серьезными сбоями, но такие случаи будут редкими), поэтому количество изменений для проверки значительно менее важно, чем в других типах Реализация FlaggedRevs, а также, очевидно, потому, что он не используется на таком большом количестве страниц. Кенарий ( разговор ) 14:30, 22 мая 2010 (UTC)
- Способ вики - быть максимально открытым как можно дольше. Это испытательный срок. Поэтому мне кажется, что лучший способ узнать, есть ли опасения по поводу автоподтвержденных пользователей, играющих в систему или вызывающих проблемы каким-либо образом, - это начать с предоставления права автоподтвержденным пользователям, а затем уменьшить его масштаб после теста, если у нас есть эмпирические данные. доказательства того, что они делают что-то не так. - Джимбо Уэльс ( разговор ) 15:10, 22 мая 2010 г. (UTC)
- Я бы согласился с этим, если бы это было пассивное право, и это уже тот случай, когда на помеченных защищенных страницах все автоматически подтвержденные пользователи автоматически проверяются, если предыдущая ревизия есть, но здесь мы говорим о проверке правок других пользователей. Маловероятно, что неопытные пользователи даже знают, как читать различия, это наверняка приведет к проблемам с удобством использования, запутав их и т. Д. Я думаю, что автопродвижение было бы гораздо лучшим компромиссом, поэтому мы можем по крайней мере удалить право из хорошего. пользователи веры злоупотребляют правом вместо того, чтобы блокировать их и позволяют немного поднять планку. Еще один момент: если сообщество не удовлетворено пробной версией, что наиболее вероятно, если все автоподтвержденные пользователи смогут просмотреть ее и ее последствия, тогда сообщество просто больше не захочет FlaggedRevs. Кенарий ( разговор ) 16:23, 22 мая 2010 (UTC)
- Я не понимаю этой логики, поэтому сообщество предпочтет гораздо менее ограничительный статус-кво, чем FlaggedRevs, потому что FlaggedRevs недостаточно ограничивает? Единственная душа ( разговор ) 18:09, 22 мая 2010 (UTC)
- На самом деле это не вопрос более или менее строгих ограничений. Все правки автоматически подтвержденных пользователей уже автоматически проверяются, если предыдущая версия проверяется, и случаи, когда автоматически подтвержденный пользователь редактирует частично отмеченную защищенную страницу с последней версией, которая не проверяется, должны быть довольно редкими. Кенарий ( разговор ) 18:23, 24 мая 2010 (UTC)
- Я ожидаю, что во время испытания это будет редкостью, но я не уверен, что произойдет позже, когда энтузиазм по поводу активного анализа утихнет. Есть еще кое-что, что нелегко измерить, и это психологический барьер, который может помешать автоматически подтвержденным пользователям редактировать страницу в первую очередь, когда они знают, что их правки не появятся сразу. Единственная душа ( разговор ) 19:58, 24 мая 2010 (UTC)
- На самом деле это не вопрос более или менее строгих ограничений. Все правки автоматически подтвержденных пользователей уже автоматически проверяются, если предыдущая версия проверяется, и случаи, когда автоматически подтвержденный пользователь редактирует частично отмеченную защищенную страницу с последней версией, которая не проверяется, должны быть довольно редкими. Кенарий ( разговор ) 18:23, 24 мая 2010 (UTC)
- Я не понимаю этой логики, поэтому сообщество предпочтет гораздо менее ограничительный статус-кво, чем FlaggedRevs, потому что FlaggedRevs недостаточно ограничивает? Единственная душа ( разговор ) 18:09, 22 мая 2010 (UTC)
- Если за переходом не стоит техническая причина, которая приведет к значительным задержкам (например, более чем на месяц) или сделает развертывание фактически невозможным, технический персонал не должен превалировать над консенсусом сообщества. Я согласен с Cenarium в том, что, если по какой-либо причине испытание пройдет плохо, сообщество почти наверняка не примет FlaggedRevs в любой форме. Г-н З- ман 16:40, 22 мая 2010 г. (UTC)
- Всем привет. Проблема многообразна: 1. Есть проблема с удобством использования. Ручки и виджеты, необходимые для реализации полного предложения в том виде, в каком оно написано, требуют гораздо большего внимания к удобству использования, чем у нас есть время для реализации. 2. значения по умолчанию. если люди по умолчанию не включены в группу проверки, будет много очень квалифицированных редакторов, которые не будут участвовать из-за предвзятости статус-кво . 3. Основная цель этой функции - статьи, которые в настоящее время находятся в полузащищенном статусе. Возникнут законные сомнения относительно использования этого в качестве замены полузащиты, если люди, которые в настоящее время имеют право на отображение своих правок, немедленно теряют эту способность.
Я не привязан к конфигурации, которая указана в Википедии: защита с флажками и патрулируемые версии / пробная версия , и я рад представить другую точку зрения другим сотрудникам WMF, если вы все сможете убедить меня, что то, что там наверху, неправильно, но все, что мы придумываем, должно быть проще, чем то, что написано в Википедии: помеченная защита , и должно быть очень быстро закреплено, чтобы эта функция была запущена своевременно. - RobLa ( разговор ) 17:47, 22 мая 2010 г. (UTC)- Что касается №1, я не согласен. Этот аспект функции FlaggedRevs предназначен для администраторов и опытных пользователей. Удобство использования - главная проблема для вещей, ориентированных на новых пользователей и читателей. Но для этих групп результат в любом случае будет в основном одинаковым. Что касается пункта 2, наш опыт с откатом, автоматическим просмотром и создателем учетной записи говорит об обратном. Это также можно смягчить, используя более строгую систему автопродвижения, чем автоподтверждение. Вы должны быть привязаны к конфигурации, согласованной сообществом. За исключением случаев, когда правление соглашается изменить что-либо или уполномоченный сотрудник не изменяет это как действие офиса или из-за реальных технических проблем (то есть вещи, которые могут привести к сбою сайта, а не просто предполагаемые проблемы с удобством использования, которые у WMF не было проблем с закреплением на других вики) персонал должен выполнять то, о чем согласилось сообщество. Так все работало годами, и я не вижу причин менять это. Вы не запускаете этот проект. Вы не можете отменять политику сообщества. Г-н З- ман 18:21, 22 мая 2010 г. (UTC)
- На этом этапе юзабилити - это второстепенная проблема. Я готов поддержать здесь здоровое количество дебатов, но в первую очередь нужно беспокоиться о том, чтобы получить работающую реализацию программного обеспечения, запрошенного сообществом. Я уже разочарован тем, что до сих пор не реализованы патрулируемые версии (которые должны быть намного проще реализовать, чем защита с флажками), но я думаю, что на данный момент совершенно неразумно, что юзабилити является проблемой блокировки для этого программного обеспечения. {{ Nihiltres | говорить | правки | ⚡ }} 19:02, 22 мая 2010 г. (UTC)
- Всем привет. Проблема многообразна: 1. Есть проблема с удобством использования. Ручки и виджеты, необходимые для реализации полного предложения в том виде, в каком оно написано, требуют гораздо большего внимания к удобству использования, чем у нас есть время для реализации. 2. значения по умолчанию. если люди по умолчанию не включены в группу проверки, будет много очень квалифицированных редакторов, которые не будут участвовать из-за предвзятости статус-кво . 3. Основная цель этой функции - статьи, которые в настоящее время находятся в полузащищенном статусе. Возникнут законные сомнения относительно использования этого в качестве замены полузащиты, если люди, которые в настоящее время имеют право на отображение своих правок, немедленно теряют эту способность.
- Могу ли я спросить (как человека, который только начал редактирование с момента обсуждения, опроса и т. Д.) В рамках этой системы (то есть той, которая предлагается здесь для пробной версии, с автоматически подтвержденными пользователями, являющимися рецензентами), будет ли каждое изменение, выполненное автоматически подтвержденным используемым, отмечать предыдущую версию как патрулировали? Было бы, не так ли? Несомненно, это приведет к тому, что большое количество версий будет помечено как проверяемые автоматически подтвержденными пользователями, которые не хотели этого делать, а просто пытались внести изменения? - Дурак Лира ( обсуждение | вклад ) 19:21, 22 мая 2010 г. (UTC)
- Нет, если предыдущая редакция (то есть текущая версия) не проверялась, то проверка редактирования является активным процессом (для этого требуется установить флажок или дополнительную кнопку), а не пассивным. Это не зависит от реальной используемой системы и будет одинаковым для любого использования FR. Г-н З- ман 21:26, 22 мая 2010 г. (UTC)
- Я против FlaggedRevs, так как он внезапно отключает читателей от редакции. В Викиучебниках зарегистрированные пользователи видят «последнюю версию», а публика видит старую версию. Для текущих событий это был бы еще один шаг для получения необходимого изменения (факт фиксированного). РГ: Система (одобрение), подобная RFA, была бы пыткой; с таким же успехом можно прекратить редактирование для всех пользователей, кроме администраторов. Идея удобства использования и «кто угодно может редактировать» будет разрушена; поле редактирования достаточно сбивает с толку, не запутывая «Ревизия 5428294 отклонена администратором». Слишком много автоматически подтвержденных пользователей, чтобы это работало; слишком мало пользователей будет выбрано в качестве рецензентов. Возможный способ использования групп - привязать разрешение отката к FlaggedRevs; Я думаю, что это должно решать сообщество, а не мистер Уэльс. Кроме того, другие проекты (Викиучебники и т. Д.) Не похожи на Википедию! (посмотрите, чем WN отличается от WP ; меня расстраивает то, что контент между WP и WN не может быть скопирован.) Наконец, WP: TROLLs , подрывные редакторы, вандалы, перемещающие страницы и т. д., будут иметь новый способ испортить система без тонны людей , знающих (большинство людей этой природы автоподтверждённые) .-- м о ɳ о 20:30, 22 мая 2010 (UTC)
- Продолжение: я заметил, что комментарий о патрулированных оборотах будет намного проще реализовать ( WP: HG , WP: IG , WP: LUPINE ), чем FR, и никого не запутает. Вместо того, чтобы переопределять систему, вы можете просто добавить что-то новое, а не что-то другое. - м о ɳ о 20:35, 22 мая 2010 (UTC)
- Похоже, вы путаете FlaggedRevs (расширение MediaWiki) с Flagged Revisions (конкретная реализация этого расширения). План английской Википедии состоит в том, чтобы использовать другую систему помеченной защиты и патрулируемых исправлений . Защита с пометкой, по сути, использует помеченные версии только на страницах, которые в противном случае были бы защищены в некоторой степени. Патрулируемые ревизии (которые вы, кажется, понимаете лучше) - это просто пассивные флажки «Эта ревизия рассмотрена» для исправлений, которые, вероятно, будут полезны для обслуживания и устранения вандализма. Пожалуйста, примите во внимание эти различия, комментируя эти обсуждения. Ура, {{ Nihiltres | говорить | правки | ⚡ }} 15:33, 23 мая 2010 г. (UTC)
- Предоставление авторецензентам права на просмотр кажется разумной идеей. Но мы должны изменить критерии квалификации авторевьюера. Так как не многие сделали около 75 статей. Мы могли бы изменить критерии, чтобы сказать 100 хороших правок. Грэм Бартлетт ( разговор ) 03:57, 23 мая 2010 (UTC)
- Это действительно звучит как хорошая идея. Но я думаю, что 100 хороших правок недостаточно, потому что авторевьюер, как я полагаю, по-прежнему будет иметь те же функции, что и сейчас. Итак, по крайней мере, 5 новых статей, на которые есть ссылки и (по крайней мере, пограничные), плюс 100 хороших правок. Я говорю это как человек, у которого есть 2k правок, но только четыре статьи, три из которых не имеют источника. Однако, если это возможно, я бы хотел, чтобы эти две группы были разделены. Я хотел бы быть рецензентом, такая работа мне нравится, но я буду кошмарным автором рецензирования, потому что я мало работал с фактическим созданием контента. Возможно, как сказал моно, из тех, кто может стать хорошими рецензентами, будут люди, которые уже «одобряют» правки с помощью Huggle - откатывания. {{ Соня | говорить | simple }} 08:29, 23 мая 2010 г. (UTC)
- Хорошо как тот, кто вносит много правок, но редко начинает статьи. Я могу сказать, что вы немедленно столкнетесь с этим. Возможно, вы захотите просмотреть мои 500 исправлений опечаток сегодня? Да??? Нет, не думал . ;) С уважением, SunCreator ( разговор ) 09:43, 23 мая 2010 (UTC)
- Соня хорошо замечает; Простым решением было бы включить права рецензента в autoreviewer (чтобы дать нам немедленную базу доверенных людей для отметки оборотов; я также мог видеть, что это включается неявно с откатом и соответствием, оба уровня доверия), но должно быть также быть еще одной группой пользователей для простой пометки изменений для тех, кто не соответствует критериям предоставления автоматического просмотра (или других прав). - xeno talk 15:24, 9 июня 2010 г. (UTC)
- В духе возражения SunCreator я не уверен, что «x новых ссылочных статей» будет достаточно легким критерием для удовлетворения, особенно учитывая, как часто люди утверждают, что с более чем 3 миллионами статей количество заметных тем в Википедии приближается насыщенность ... - Дуплод ( разговор ) 16:46, 23 мая 2010 (UTC)
- Хорошо как тот, кто вносит много правок, но редко начинает статьи. Я могу сказать, что вы немедленно столкнетесь с этим. Возможно, вы захотите просмотреть мои 500 исправлений опечаток сегодня? Да??? Нет, не думал . ;) С уважением, SunCreator ( разговор ) 09:43, 23 мая 2010 (UTC)
- Я считаю, что предоставление авторецензентам прав рецензента планировалось всегда. Однако специалисты WMF FlaggedRevs решили изменить план и предоставить его всем автоматически подтвержденным пользователям - пользователям, которые внесли 10 изменений и были здесь 4 дня. Г-н З- ман 14:12, 23 мая 2010 г. (UTC)
- Это кажется разумным как по методу, так и по объему. Это чем-то похоже на критерии викиучебников . Четыре дня и 10 правок работают хорошо, чтобы остановить реакцию и вандалов; подтверждено, чтобы вы знали, что у них есть учетная запись электронной почты и с ними можно связаться. Предоставление прав рецензента всем подтвержденным пользователям, потому что в противном случае Википедия прекратит редактирование с самого начала. С уважением, SunCreator ( обсуждение ) 15:51, 23 мая 2010 г. (UTC)
- Автоподтверждение не требует адреса электронной почты. Викиучебники требуют значительно большего опыта, прежде чем права рецензента будут предоставлены автоматически - всего 100 не удаленных правок, 30 дней, не менее 50 правок контента на 10 уникальных страницах, отсутствие блоков и установленный адрес электронной почты. Г-н З- ман 16:44, 23 мая 2010 г. (UTC)
- Это кажется разумным как по методу, так и по объему. Это чем-то похоже на критерии викиучебников . Четыре дня и 10 правок работают хорошо, чтобы остановить реакцию и вандалов; подтверждено, чтобы вы знали, что у них есть учетная запись электронной почты и с ними можно связаться. Предоставление прав рецензента всем подтвержденным пользователям, потому что в противном случае Википедия прекратит редактирование с самого начала. С уважением, SunCreator ( обсуждение ) 15:51, 23 мая 2010 г. (UTC)
- Вот причина выбора autoconfirmed в качестве первого уровня защиты с флажками для развертывания. Основными кандидатами на помеченную защиту являются статьи, которые в настоящее время находятся под полузащитой. Статьи, находящиеся под полузащитой, в настоящее время полностью доступны для редактирования автоподтвержденными пользователями. Если мы используем любой другой уровень, кроме автоматически подтвержденного, то помещение их под помеченную защиту фактически отнимает права, которыми эти пользователи ранее владели. Мы всегда можем добавить больше уровней позже, но идея состоит в том, чтобы начать с наиболее инклюзивного уровня, чтобы люди могли освоиться с самой функцией, а затем расширять ее по запросу сообщества. - RobLa ( разговор ) 17:27, 23 мая 2010 г. (UTC)
- Я понимаю ваше обоснование своего предпочтения, но каково ваше обоснование игнорирования консенсуса сообщества и подмены своего собственного мнения? (И я думал, что причина была в удобстве использования?) Потребовалось больше года, чтобы получить испытание, по которому мы достигли консенсуса в апреле прошлого года. Теперь вы меняете вещи, основываясь на собственном мнении. Простите меня, если я абсолютно не верю в то, что команда FlaggedRevs сделает что-либо, основанное на «требовании сообщества». Г-н З- ман 17:43, 23 мая 2010 г. (UTC)
- Джимбо оспаривает утверждения СМИ о том, что новая система менее инклюзивна. Когда вы смотрите на исходное предложение, средства массовой информации кажутся частично правильными, поскольку предложение отнимает права у автоматически подтвержденных пользователей, как сказал RobLa. Единственная душа ( разговор ) 17:53, 23 мая 2010 (UTC)
- Меня не волнует, что говорят СМИ. Я хочу знать, почему сотрудники WMF наделили себя властью управлять сообществом по вопросам, которые не являются серьезными техническими или юридическими проблемами. До сих пор WMF ограничивал свое участие в установлении местных политик и процедур вещами, которые представляют серьезную проблему для сайта (технические изменения, необходимые для поддержания работы сайта, уведомления DMCA и т. Д.) Или вещами, которые не являются явный консенсус по поводу (недавнее изменение скина, большинство новых функций). Здесь они, кажется, просто подменяют свои собственные предпочтения, потому что им просто не нравится то, что решило сообщество. Это серьезный сдвиг, и я откровенно шокирован тем, что они делают это так легкомысленно. Г-н Z- ман
- Привет, мистер Z-человек. Я знаю, что вы разочарованы тем, как мы оказались там, где мы находимся, но я прошу вас проявить добросовестность .
Мы не игнорировали консенсус сообщества. Насколько я могу судить, отзывы сообщества по этим конкретным вопросам были неоднозначными. Например, первый опрос по этому вопросу более года назад разделили 22 сторонников и 32 против. Хотя это может быть относительно сильное большинство, это не консенсус. В сообществе размером с сообщество английских редакторов Википедии это даже не похоже на кворум. Более поздний опрос об автопродвижении был таким же небольшим: 13 сторонников, 19 противников и 2 нейтральных. Мое чтение опросов и других обсуждений показывает, что типичный член сообщества не отслеживает вещи на том уровне детализации, который мы здесь обсуждаем.
На этом этапе я создал конфигурацию и разместил сообщение на wikien-l, уведомив всех о том, что я вношу изменения и что все будет в постоянном движении . Позже я узнал, что в WMF были и более ранние разговоры, и что многие люди там согласились с чем-то даже более простым, чем то, что я опубликовал сначала . Поговорив с ними, я убедился, что они правы, и соответственно изменил страницу.
Отвечая на ваш вопрос об обосновании, причиной для упрощения его до одного варианта было удобство использования и возможность объяснить, как работает функция, когда мы ее представляем. Обоснование выбора того варианта, который мы сделали, объяснено выше.
Мы стремимся сделать это испытание успешным. Мы хотим, чтобы сообществу редакторов понравилась эта функция. Мы будем восприимчивы к причинам, по которым то, что мы предложили, не будет работать в течение короткого периода испытания. Давайте сосредоточимся на предложении, чтобы что-то реализовать. Спасибо! - RobLa ( разговор ) 21:49, 23 мая 2010 г. (UTC)
- Какое предложение? Возможность выбора между 2 заранее заданными именами для системы? Я не вижу, чтобы здесь что-то предлагалось, я вижу, что фонд говорит: «Ну, вы просили об этом, но мы решили дать вам это вместо этого, мы надеемся, вам это понравится». Г-н З- ман 22:55, 23 мая 2010 г. (UTC)
- Никаких предложений не поступало, я должен был сообщить об этом сейчас, поскольку вы не принесли это для публичного обсуждения. Сотрудники фонда обсуждали это с начала апреля; влиятельное лицо (не Джимбо) высказало мнение, что мы должны предоставить права на проверку всем автоподтвержденным пользователям, Аарона попросили прокомментировать технический аспект, и он высказал несколько возражений, некоторые из приведенных здесь причин, затем он предложил спросить меня. Я изложил позицию сообщества, как я ее вижу, и впоследствии, очевидно, было достигнуто общее согласие, что автопродвижение было бы хорошим компромиссом. На мое последнее электронное письмо не было ответа, и теперь я узнал, что вопросов больше нет, было решено предоставить права просмотра всем автоматически подтвержденным пользователям, так зачем игнорировать Аарона и озабоченность сообщества, почему я решил это с минимальным участием сообщества ? Кенарий ( разговор ) 03:10, 25 мая 2010 (UTC)
- Джимбо оспаривает утверждения СМИ о том, что новая система менее инклюзивна. Когда вы смотрите на исходное предложение, средства массовой информации кажутся частично правильными, поскольку предложение отнимает права у автоматически подтвержденных пользователей, как сказал RobLa. Единственная душа ( разговор ) 17:53, 23 мая 2010 (UTC)
- Я понимаю ваше обоснование своего предпочтения, но каково ваше обоснование игнорирования консенсуса сообщества и подмены своего собственного мнения? (И я думал, что причина была в удобстве использования?) Потребовалось больше года, чтобы получить испытание, по которому мы достигли консенсуса в апреле прошлого года. Теперь вы меняете вещи, основываясь на собственном мнении. Простите меня, если я абсолютно не верю в то, что команда FlaggedRevs сделает что-либо, основанное на «требовании сообщества». Г-н З- ман 17:43, 23 мая 2010 г. (UTC)
- Это действительно звучит как хорошая идея. Но я думаю, что 100 хороших правок недостаточно, потому что авторевьюер, как я полагаю, по-прежнему будет иметь те же функции, что и сейчас. Итак, по крайней мере, 5 новых статей, на которые есть ссылки и (по крайней мере, пограничные), плюс 100 хороших правок. Я говорю это как человек, у которого есть 2k правок, но только четыре статьи, три из которых не имеют источника. Однако, если это возможно, я бы хотел, чтобы эти две группы были разделены. Я хотел бы быть рецензентом, такая работа мне нравится, но я буду кошмарным автором рецензирования, потому что я мало работал с фактическим созданием контента. Возможно, как сказал моно, из тех, кто может стать хорошими рецензентами, будут люди, которые уже «одобряют» правки с помощью Huggle - откатывания. {{ Соня | говорить | simple }} 08:29, 23 мая 2010 г. (UTC)
Поддержите озабоченность RFC (если она технически точна) - мне было бы неудобно, если права рецензента будут автоматически распространяться, автоматически подтвержденным пользователям или любым другим способом. Причины, которые говорят со мной:
- Это «просто испытание». Но это серьезное испытание, и вся эффективность подхода помеченных изменений будет тщательно изучена здесь и с комментариями в СМИ. Ослабленная версия, которая позволяет любому, включая вандалов и пользователей, которые не продемонстрировали, что они понимают наши политики и критерии ( что такое «вандализм, а что нет» ), - в любом случае получить права рецензента, не поможет нам оценить инструмент и будет увеличиваться шансы на отрицательные оценки.
- Мы ожидаем, что многие люди получат этот инструмент. Многие тоже получают откат . Но есть разница между «многие» и «без разбора». Поддержите «многих», выступите против «неизбирательного / автоматизированного» по причинам, с которыми также согласилось сообщество.
- Инструмент, требующий двойной проверки таким образом, слишком отличается от обсуждаемого . Цель состоит в том, чтобы сэкономить работу за счет наличия у пользователей некоторого доверия и некоторого контроля для получения такого доступа. Не каждый".
Если заявление RFC является точным, я бы согласился с ним как с проблемой. FT2 ( Обсуждение | электронная почта ) 00:36, 24 мая 2010 г. (UTC)
- Поддержите отдельную группу пользователей. Однако доступ к группе пользователей должен быть подобен откату, который может быть предоставлен по запросу любым администратором. Это следует выделить в отдельную группу из-за возможности добросовестного злоупотребления, не говоря уже о других видах злоупотреблений; затем оно может быть легко отозвано любым администратором без блокировки, ожидающего обсуждения и т. д. Право также может быть автоматическим с автоподтверждением, но может быть отменено отдельно. В качестве пробной версии безопаснее всего, чтобы это было как откат. - Абд ( разговор ) 14:42, 24 мая 2010 г. (UTC)
- 4 дня и 10 правок на рассмотрение? Не уверен, что это хорошая идея. Нужна отдельная группа. ++ Lar : t / c 01:36, 25 мая 2010 г. (UTC)
- Обращение к пунктам RobLa:
- Проблемы с удобством использования возникнут после удаления группы рецензентов, а не наоборот. Админы и опытные пользователи уже привыкли к относительно сложным инструментам, им не страшны два новых уровня защиты, а читатели и неопытные пользователи не будут беспокоиться. Кроме того, запрошенная конфигурация уже запущена и работает на сайте тестирования и работает достаточно хорошо; удобство использования не является синонимом «бесконечной полировки». Многие администраторы протестировали интерфейс и не обнаружили в нем каких-либо существенных проблем с удобством использования, они могут его использовать, и даже тогда они знают, где найти помощь, если это необходимо, нет проблем. Тем не менее, возникнет проблема удобства использования, и большая проблема, если неопытные пользователи с автоподтверждением столкнутся со странными вещами, называемыми «различия» для «обзора».
- Предполагаемая предвзятость статус-кво: мы собираемся использовать отчеты базы данных для выявления пользователей, которые, вероятно, достаточно опытны, чтобы получить право на проверку или в качестве второго варианта автопродвижение, чтобы его устранить.
- Рискуя повторять это снова и снова, автоподтвержденные пользователи автоматически проверяют свои правки, если проверяется предыдущая ревизия; случаи, когда автоподтвержденный пользователь редактирует помеченную защищенную страницу с непроверенной последней ревизией, должны быть довольно редкими. С другой стороны, если опытным пользователям придется дважды проверять отзывы, у них будет меньше времени для проверки новых правок IP-адресов и пользователей без автоподтверждения.
- Что на WP: Флаговая защита устарела, запрос сообщества находится на WP: FPPR, и вы знаете, что это именно та конфигурация, которая находится на сайте тестирования. Я не понимаю аргумента «это проще», читатели и большинство пользователей не знают внутреннего, это будет иметь значение только для администраторов и пользователей, которые будут проверять правки, уверяю вас, они справятся с этим уровнем сложности. .
- Если мы не получаем то, что сообщество хочет от реализации, тогда какой смысл иметь пробную версию, так далекую от того, что сообщество могло бы поддержать в использовании в долгосрочной перспективе? Вы можете подумать, что два опроса по автопродвижению анекдотичны, но совершенно очевидно, что сообщество отклонило первую версию помеченной защиты, без группы рецензентов, в пользу этой, с группой рецензентов. Кенарий ( разговор ) 03:10, 25 мая 2010 (UTC)
- Я вообще с Z-man и Cenarium. Можем ли мы просто продолжить судебное разбирательство, как обсуждалось , и больше не говорить об этом до смерти? Это испытание, для взываем громко: Если мы запустим в примечательное отставание, мы затем изменить процесс.
Чтобы концепция оставалась в некоторой степени полезной, группа рецензентов должна быть достаточно большой и активной, чтобы отставание оставалось небольшим, но достаточно маленькой, чтобы содержать только достаточно надежных пользователей. Если нам это удастся, редактирование останется таким же открытым для автоподтверждений, как и раньше, и более открытым для IP-адресов.
Четыре дня / десять правок - это далеко не то, что требуется для того, чтобы процесс рецензирования оставался значимым. Невозможность отозвать статус рецензента и необходимость возвращаться к блокировке в случае, если это изменение еще хуже. Амальтея 13:51, 25 мая 2010 г. (UTC)- Амальтея, причина, по которой я пошел по тому пути, который я сделал, заключалась в том, что я пытался согласовать конфигурацию с тем, что было на веб-странице. Выяснив, что у меня недостаточно информации на веб-странице для этого, я решил исправить это и перейти к упрощенной версии. Затем, поговорив с людьми из WMF о разговорах, которые они вели еще до моего приезда, они придумали что-то еще более простое. Итак, я пошел с этим. - RobLa ( разговор ) 16:33, 25 мая 2010 г. (UTC)
- Я не понимаю. Весь код конфигурации PHP был написан и выложен в течение нескольких месяцев. О чем ты говоришь? - MZMcBride ( разговор ) 16:40, 25 мая 2010 г. (UTC)
- Я не смог найти ничего актуального. Недавно я создал конфигурацию User: RobLa / Flagged Rev для английской Википедии , которая имеет очень недавнюю конфигурацию и не соответствует тому, что кто-то хочет развернуть на en.wp. - RobLa ( разговор ) 18:32, 25 мая 2010 г. (UTC)
- Просто раскатайте что-нибудь . Не выкладывайте компьютерные распечатки, включите настоящую вещь. Может быть , кто - то будет заметить (помните , что случилось с этой ерундой вектор - мы просто перешли обратно MonoBook и перемещается вдоль). К востоку от Борщова ( разговор ) 19:23, 25 мая 2010 (UTC)
- Похоже, это сделал Аарон . Не уверен, о чем это .... - MZMcBride ( разговор ) 19:30, 25 мая 2010 г. (UTC)
- Я не смог найти ничего актуального. Недавно я создал конфигурацию User: RobLa / Flagged Rev для английской Википедии , которая имеет очень недавнюю конфигурацию и не соответствует тому, что кто-то хочет развернуть на en.wp. - RobLa ( разговор ) 18:32, 25 мая 2010 г. (UTC)
- Как и MzMcBride, у меня создалось впечатление, что все это было настроено очень давно в тестовой реализации. Но как бы то ни было, теперь, когда это недоразумение, надеюсь, прояснилось, можете ли вы согласиться с тем, что решило сообщество? На данный момент права группы на flaggedrevs.labs кажутся такими, как задумано (в этом отношении). Амальтея, 12:05, 26 мая 2010 г. (UTC)
- Я не понимаю. Весь код конфигурации PHP был написан и выложен в течение нескольких месяцев. О чем ты говоришь? - MZMcBride ( разговор ) 16:40, 25 мая 2010 г. (UTC)
- Чертовски хорошее резюме. Включите, посмотрим, что будет. К востоку от Борщова ( разговор ) 19:23, 25 мая 2010 (UTC)
- Амальтея, причина, по которой я пошел по тому пути, который я сделал, заключалась в том, что я пытался согласовать конфигурацию с тем, что было на веб-странице. Выяснив, что у меня недостаточно информации на веб-странице для этого, я решил исправить это и перейти к упрощенной версии. Затем, поговорив с людьми из WMF о разговорах, которые они вели еще до моего приезда, они придумали что-то еще более простое. Итак, я пошел с этим. - RobLa ( разговор ) 16:33, 25 мая 2010 г. (UTC)
- Я вполне могу быть в меньшинстве здесь, но если эта новая функция требует, чтобы администраторы назначили (и косвенно удалили) какие-либо новые права, то я просто проигнорирую любые статьи, к которым она применяется. Malleus Fatuorum 17:09, 25 мая 2010 г. (UTC)
- Меньшинство из двух, Маллеус. Прочитав это нелепое предложение, я тоже просто откажусь редактировать любые статьи, требующие от меня этого «права». Админы уже достаточно напыщенны, не давая им дальнейших возможностей запугать нас, обычных редакторов. Большой Дом 18:15, 11 июня 2010 г. (UTC)
- Статьи, защищенные ПК на уровне 2 (если они действительно используются), будут полностью защищены в противном случае, поэтому их не смогут редактировать кроме администраторов. А статьи, защищенные ПК на уровне 1, будут полузащищенными, поэтому их смогут редактировать только автоматически подтвержденные пользователи. Разве не предпочтительнее иметь возможность разрешать редактирование пользователям, которые не подтверждены автоматически? Изменения, внесенные автоматически подтвержденными пользователями, автоматически принимаются, если принимается предыдущая редакция, и из этого может быть только несколько исключений. Мне кажется, что мы выигрываем, позволяя редактировать IP-адреса и новым пользователям за счет исключительных случаев, когда автоматически подтвержденный пользователь, который не является рецензентом, может редактировать сразу после IP-адреса или нового пользователя, чьи правки еще не были проверены, и очевидно, может быть отменен (если он возвращается к последней принятой версии, она автоматически становится принятой). Кенарий ( разговор ) 21:09, 12 июня 2010 (UTC)
- Первый раз, когда я увижу, что моя правка не сразу видна, будет последней. Malleus Fatuorum 22:23, 12 июня 2010 г. (UTC)
- Это часть более крупной проблемы: «Википедия для редакторов» сильно отличается от «Википедии для читателей». Разрыв увеличивается: они видят другой дизайн страницы (вектор), они видят другой макет страницы (из-за индивидуальных настроек размера изображения каждого), и теперь они будут видеть разные тексты. Но с цензурой всего 2000 статей, шансы столкнуться с FR практически равны нулю, если только вы не решитесь заняться такими вещами, как убийство Мередит Керчер . К востоку от Борщова ( разговор ) 22:50, 12 июня 2010 г. (UTC)
- Также увеличивается разрыв между, с одной стороны, потенциальными редакторами, которые хотели бы редактировать, но не могут этого сделать, и случайными редакторами, а с другой стороны, ядром авторитетных редакторов. Мы должны стремиться восполнить этот пробел, потому что, я думаю, это экзистенциальная проблема, и незавершенные изменения помогают в этом, позволяя редактировать большему количеству людей. Кенарий ( разговор ) 23:27, 12 июня 2010 (UTC)
- Это часть более крупной проблемы: «Википедия для редакторов» сильно отличается от «Википедии для читателей». Разрыв увеличивается: они видят другой дизайн страницы (вектор), они видят другой макет страницы (из-за индивидуальных настроек размера изображения каждого), и теперь они будут видеть разные тексты. Но с цензурой всего 2000 статей, шансы столкнуться с FR практически равны нулю, если только вы не решитесь заняться такими вещами, как убийство Мередит Керчер . К востоку от Борщова ( разговор ) 22:50, 12 июня 2010 г. (UTC)
- Первый раз, когда я увижу, что моя правка не сразу видна, будет последней. Malleus Fatuorum 22:23, 12 июня 2010 г. (UTC)
- Статьи, защищенные ПК на уровне 2 (если они действительно используются), будут полностью защищены в противном случае, поэтому их не смогут редактировать кроме администраторов. А статьи, защищенные ПК на уровне 1, будут полузащищенными, поэтому их смогут редактировать только автоматически подтвержденные пользователи. Разве не предпочтительнее иметь возможность разрешать редактирование пользователям, которые не подтверждены автоматически? Изменения, внесенные автоматически подтвержденными пользователями, автоматически принимаются, если принимается предыдущая редакция, и из этого может быть только несколько исключений. Мне кажется, что мы выигрываем, позволяя редактировать IP-адреса и новым пользователям за счет исключительных случаев, когда автоматически подтвержденный пользователь, который не является рецензентом, может редактировать сразу после IP-адреса или нового пользователя, чьи правки еще не были проверены, и очевидно, может быть отменен (если он возвращается к последней принятой версии, она автоматически становится принятой). Кенарий ( разговор ) 21:09, 12 июня 2010 (UTC)
- Меньшинство из двух, Маллеус. Прочитав это нелепое предложение, я тоже просто откажусь редактировать любые статьи, требующие от меня этого «права». Админы уже достаточно напыщенны, не давая им дальнейших возможностей запугать нас, обычных редакторов. Большой Дом 18:15, 11 июня 2010 г. (UTC)
- Это должна быть автоматически предоставленная функция. Меня никогда не убеждали, что FP сделает что-либо, кроме добавления слоя бюрократии, и сделает больше, чтобы закрыть редактирование на этих страницах, чем открыть его, но мое мнение по этому поводу было в меньшинстве. путь с самого начала. Честно говоря, меня не волнует, сможет ли User: Never Edited Before теперь попытаться добавить вандализм Рональду Рейгану - исправление, которое теперь должно быть фактически проверено настоящим редактором вместо того, чтобы автоматически отклоняться нашим программным обеспечением. - если Пользователь: редактировал в течение пяти лет, но не интересовался RFA и помогал улучшить ту же статью, должен * запросить специальное разрешение *, чтобы продолжить редактирование точно так же, как и в течение пяти лет.
Нет вообще никаких оснований полагать, что будет какая-то выгода, и есть много причин полагать, что мы делаем работу для людей, которым теперь придется проверять правки, которые никогда бы не прошли через полузащиту. Что еще более важно, мы лишили прав редакторов, составляющих основу проекта, и заставим их просить разрешения, которое может быть произвольно отказано или отозвано администраторами, не имеющими никакого представления о качественном контенте.
Предложите, чтобы любой, у кого есть один месяц и более 50 правок, имел возможность автоматического рецензирования, и чтобы эта же группа имела возможность рецензировать. Давайте не будем стрелять себе в ногу больше, чем нужно с этим расширением. Нам не нужна Википедия, чтобы стать более MMORPG, чем она уже есть. Рискер ( разговор ) 02:06, 11 июня 2010 (UTC)
- Права будут предоставлены автоматически (если мы используем автопродвижение) или полуавтоматически и вручную на основе отчетов базы данных опытным пользователям, поэтому большинству не придется просить об этом.
- За исключением редких случаев, когда они редактируют помеченную защищенную страницу с непроверенной последней версией или когда она защищена на уровне рецензента, все автоматически подтвержденные пользователи проверяются автоматически, поэтому разрешение не требуется.
- Мы не откажемся от полузащиты, предметы, подверженные постоянному вандализму, должны быть полузащищенными, поскольку использование на них помеченной защиты действительно не пойдет на пользу проекту в целом. Кенарий ( разговор ) 02:40, 11 июня 2010 (UTC)
- Администраторы действительно могут удалить это разрешение, это необходимо, точно так же, как они могут полностью заблокировать пользователей, у нас будут рекомендации относительно того, когда удаление целесообразно - я не думаю, что экземпляры будут такими противоречивыми, в отличие от отката, которым легче злоупотреблять в редактировать войны например. Кенарий ( разговор ) 02:51, 11 июня 2010 (UTC)
- Что ж, учитывая, что «группы», рассматриваемые как модели для «автоматического» предоставления, - это средство отката (которое в основном используется для вандализма), создатель учетной записи (которое вообще не имеет ничего общего с контентом) и средство автоматического просмотра (с ожиданием 75 статей), мы по-прежнему оставляем подавляющее большинство компетентных редакторов на обочине дороги. RobLa прав, оставьте его на уровне автоподтверждения, который назначается программным обеспечением, а не людьми. Если странице требуется более серьезная защита, она должна быть защищена должным образом. Я считаю, что настало время заявить заранее, что администраторы, которые злоупотребляют этим инструментом, также должны быть удалены, даже если это означает их отказ от использования (на самом деле, я считаю, что это должно быть верным для любого инструмента, который использует администратор), и что несоответствующее удаление чьего-либо доступа рецензента (или любого другого инструмента) также должно быть основанием для отказа. Мое подавляющее предпочтение отдается автоматическому предоставлению доступа к этому инструменту и очень, очень низкому порогу без какого-либо вмешательства человека, за исключением, возможно, того, чтобы администраторы предоставили его раньше. А описание «как это работает» указывает на то, что если в очереди на публикацию статьи есть еще одна непроверенная правка, последующие правки не будут автоматически выпущены. Рискер ( разговор ) 18:40, 11 июня 2010 (UTC)
- Да, но это должно быть редко. Критериями для DBR являются не только другие группы, но и независимо количество правок и время с момента первого редактирования, начиная с высокого, чтобы избежать слишком большого количества результатов, а затем понижать рейтинг. Да, право просматривать правки других пользователей должно быть предоставлено обильно, какой-то полностью автоматический способ может быть приемлемым, но у нас нет другого выбора, кроме как принять во внимание необходимый опыт и возможность злоупотреблений, иначе система будет бесполезной. Если удаление прав администраторами-мошенниками является такой большой проблемой, то мы можем более строго регулировать удаление или даже разрешить удаление только бюрократам или распорядителям. Кроме того, что вы думаете о специальном процессе удаления удаляемых администратором групп пользователей вместо того, чтобы делать это по усмотрению администратора? Кенарий ( разговор ) 19:22, 11 июня 2010 (UTC)
- (ec) Опять же, главное, что до этого почти никогда не доходит. Если у нас есть задержка проверки более чем на несколько минут, то у нас либо слишком мало активных рецензентов, работающих над отставанием, либо слишком много статей с таким уровнем защиты.
Если вы вместо этого автоматически добавляете людей в группу отзывов после очень низкого порога, вы обесцениваете ее . Это не помогло бы защитить неясные, неотслеживаемые BLP, и сделало бы защиту ПК уровня 2 полным фарсом.
Рецензенты должны быть редакторами, которые разбираются в политике в отношении содержания. Я совершенно нормально отношусь к тому, что раздаю это обильно и требую обсуждения, чтобы убрать это. Лично, судя по опасениям, которые я слышу о злоупотреблениях, я думаю, что вам действительно нужны новые администраторы.
Амальтея 19:29, 11 июня 2010 г. (UTC)- Cenarium, любой метод, который вы используете, естественно, будет иметь большое значение в пользу RC-патрулей, Hugglers, Twinklers и других пользователей сценариев автоматического редактирования; и, прямо скажем, большинство администраторов действительно не в состоянии оценить качество редактирования тех, кто просто редактирует статьи, если они сами не осведомлены о предметной области. Таким образом, порог должен быть низким. Что касается ПК уровня 2, то сам уровень - это что-то вроде фарса. Он предназначен для замены полной защиты, но нет (насколько я могу судить) энциклопедических статей под долгосрочной полной защитой. Краткосрочная полная защита затрагивает лишь крошечную горстку статей в любой момент времени, и обычно это касается редактирования враждебных действий или некоторой серьезной степени вандализма. Споры по поводу правок следует обсуждать на страницах обсуждения, а не использовать функцию «рецензирования», где война редактирования может быть продолжена, а не разрешена, и где редактор с возможностью рецензирования будет иметь явное преимущество. Если статья защищена из-за вандализма (нечастое явление, поскольку полузащита решает почти все эти случаи), мы тратим драгоценное время добровольцев на то, чтобы очистить очередь на рассмотрение от вандалистских правок, которые были бы автоматически отклонены. с помощью программного обеспечения и выяснить, есть ли у них какие-либо достоинства.
Между прочим, один фактор, о котором я не вижу много дискуссий, - это кто на самом деле планирует проводить эти обзоры, что является отдельным моментом от того, кто должен иметь доступ для проведения обзоров. Не должно быть слишком сложно успевать за несколькими тысячами охваченных статей, но если программа расширится, возникнет необходимость отвлекать НАМНОГО больше редакционного времени и энергии на рецензирование правок, чем тратится в настоящее время. Рискер ( разговор ) 20:29, 11 июня 2010 (UTC)
- Я уверен, что те же редакторы, которые в настоящее время используют Huggle для проверки исправлений, будут просматривать эту очередь. Инструментам нужно будет наверстать упущенное, чтобы упростить эту задачу, но, в конце концов, это потребует меньше энергии, поскольку большинство правок будет проверяться только одним или двумя редакторами, а не всеми, кто запускает huggle одновременно, как сейчас.
Поднятый вопрос о ПК уровня 2: Одна статья, которую я имел в виду, была Джастин Бибер , который получил довольно много автоподтвержденных / b / вандализма. Но вы правы, страниц, на которых это будет полезно, не так уж много. Очевидно, не в споре о содержании.
И я действительно думаю, что большинство администраторов достаточно компетентны, чтобы оценить понимание политики в отношении контента, которое я рассматриваю как требование для группы рецензентов: если редактор показывает, что он знает, что факты должны быть получены, и был здесь в течение некоторого времени (например, в месяц, а иногда и меньше) то я, например, доволен. Просто некоторая уверенность в том, что он действительно взглянет на разницу и получит базовые знания о политике в отношении контента. Это будет, например, абсолютно и без вопросов включать всех, кто когда-либо писал, скажем, статью класса B. Без сомнения, без проблем, без вопросов. И да, любой админ, которого я знаю, может судить об этом, просмотрев несколько правок. Я очень удивлен, что ваше мнение об администраторах настолько низкое, но, опять же, вы активны в совершенно разных сферах, чем я.
Наконец, я продолжаю подвергать сомнению вашу предпосылку, что автоподтвержденные редакторы даже заметят . Абсолютное большинство их правок до сих пор сразу публикуется. Некоторые из их правок будут помещены в очередь на рассмотрение, и пройдет несколько минут, прежде чем их увидят читатели и поисковые системы. Вы с этим не согласны? Я сосредоточился на том, чтобы убедиться, что мы можем управлять этой частью, пытаясь контролировать, сколько статей помещается под защиту ПК в зависимости от отставания ожидающих изменений.
Амальтея 21:07, 11 июня 2010 г. (UTC)- PCP уровня 2 не предназначен для замены полной защиты, а PCP уровня 1 не предназначен для замены полузащиты, они предоставляют альтернативу. Было бы непрактично использовать PCP для споров, это не должно быть так, он предназначен для статей, которые подвержены постоянному использованию сокетов или сбоям, когда полузащита недостаточна. Есть довольно много примеров, вандал коперник, вандалы, подобные грампу, рунтшит, националистические воины редактирования и т. Д., Заставили нас полностью защищать множество статей в течение долгого времени. В настоящее время я могу привести среди полностью защищенных статей для других , чем спор по причинам пример сатанинского ритуального насилия , король Альфред план , куча монастырей: Amaras монастырь , Егише Arakyal монастырь , монастырь Гандзасар , ..., Брахма Кумарис Всемирный Духовный Университет , Queer коллабораций и т.д. Одновременно может быть не более нескольких десятков, но невыносимо полностью защищать их, а отныне фактически запрещать любое редактирование из-за одного постоянного разрушительного редактора. И есть также полузащищенные статьи, которые все еще подвергаются ежедневным нарушениям, которым может помочь дополнительный PCP 2-го уровня, такой как Барак Обама . Кенарий ( разговор ) 21:21, 11 июня 2010 (UTC)
- Я уверен, что те же редакторы, которые в настоящее время используют Huggle для проверки исправлений, будут просматривать эту очередь. Инструментам нужно будет наверстать упущенное, чтобы упростить эту задачу, но, в конце концов, это потребует меньше энергии, поскольку большинство правок будет проверяться только одним или двумя редакторами, а не всеми, кто запускает huggle одновременно, как сейчас.
- Cenarium, любой метод, который вы используете, естественно, будет иметь большое значение в пользу RC-патрулей, Hugglers, Twinklers и других пользователей сценариев автоматического редактирования; и, прямо скажем, большинство администраторов действительно не в состоянии оценить качество редактирования тех, кто просто редактирует статьи, если они сами не осведомлены о предметной области. Таким образом, порог должен быть низким. Что касается ПК уровня 2, то сам уровень - это что-то вроде фарса. Он предназначен для замены полной защиты, но нет (насколько я могу судить) энциклопедических статей под долгосрочной полной защитой. Краткосрочная полная защита затрагивает лишь крошечную горстку статей в любой момент времени, и обычно это касается редактирования враждебных действий или некоторой серьезной степени вандализма. Споры по поводу правок следует обсуждать на страницах обсуждения, а не использовать функцию «рецензирования», где война редактирования может быть продолжена, а не разрешена, и где редактор с возможностью рецензирования будет иметь явное преимущество. Если статья защищена из-за вандализма (нечастое явление, поскольку полузащита решает почти все эти случаи), мы тратим драгоценное время добровольцев на то, чтобы очистить очередь на рассмотрение от вандалистских правок, которые были бы автоматически отклонены. с помощью программного обеспечения и выяснить, есть ли у них какие-либо достоинства.
- Что ж, учитывая, что «группы», рассматриваемые как модели для «автоматического» предоставления, - это средство отката (которое в основном используется для вандализма), создатель учетной записи (которое вообще не имеет ничего общего с контентом) и средство автоматического просмотра (с ожиданием 75 статей), мы по-прежнему оставляем подавляющее большинство компетентных редакторов на обочине дороги. RobLa прав, оставьте его на уровне автоподтверждения, который назначается программным обеспечением, а не людьми. Если странице требуется более серьезная защита, она должна быть защищена должным образом. Я считаю, что настало время заявить заранее, что администраторы, которые злоупотребляют этим инструментом, также должны быть удалены, даже если это означает их отказ от использования (на самом деле, я считаю, что это должно быть верным для любого инструмента, который использует администратор), и что несоответствующее удаление чьего-либо доступа рецензента (или любого другого инструмента) также должно быть основанием для отказа. Мое подавляющее предпочтение отдается автоматическому предоставлению доступа к этому инструменту и очень, очень низкому порогу без какого-либо вмешательства человека, за исключением, возможно, того, чтобы администраторы предоставили его раньше. А описание «как это работает» указывает на то, что если в очереди на публикацию статьи есть еще одна непроверенная правка, последующие правки не будут автоматически выпущены. Рискер ( разговор ) 18:40, 11 июня 2010 (UTC)
Комментарий и обсуждение RobLa
Итак, мы слышим здесь озабоченность. Мы понимаем, что предоставление людям инструментов обзора, которые они, возможно, еще не понимают, потенциально может привести к проблемам. Однако я хотел бы убедиться, что все действительно понимают один важный момент, который мы здесь делаем, прежде чем мы согласимся.
Вполне вероятно, что многие статьи, находящиеся в настоящее время под полузащитой, будут помещены в ожидающие изменения. В результате здесь есть несколько разных результатов:
- В мире, где автоподтвержденные пользователи получают права на рецензию, не так много изменений в отношении их способности испортить статью. Изменения редакторов, подтвержденные автоматически, сразу видны на полузащищенных страницах, и они также будут немедленно видны на страницах ожидающих изменений. Новый уровень защиты однозначно будет ослаблением полузащищенного статуса, что позволяет довольно просто описать это преимущество. В целях пробной версии мы получаем преимущество очень большого числа пользователей, которые могут использовать элементы управления редактированием, поэтому мы действительно можем видеть новые изменения в действии и иметь больше шансов исправить проблемы интерфейса, пока это еще пробная версия. и развертывается только на относительно небольшом количестве страниц.
- В мире, где только группа рецензентов, поддерживаемая вручную, получает права на рецензирование, внезапно появляется очень большая часть сообщества, которая больше не может вносить немедленные изменения в статью . Это означает, что статьи, которые были частично защищены, теперь станут более ограниченными. Это уровень нюансов, который мы все свяжем в узлы, объясняя широкой публике, большинство из которых не поймут, как получить благословение в качестве рецензентов, и будут считать, что это выходит за рамки их времени, склонности и таланта делать случаться.
Однако я полностью понимаю, что мы очень поздно пытаемся убедить сообщество в этом. У нас много работы до запуска 14 июня, и вам тоже. Например, существует потребность в гораздо более качественной документации для конечных пользователей . Кто-то должен написать точную политику в отношении того, кто станет рецензентом. Необходима политика, согласно которой страницы могут быть включены в эту функцию. Так что, я полагаю, нам не стоит упираться в это, но я чувствовал, что должен вам лучше объяснить, как мы сюда попали. Спасибо - RobLa ( разговор ) 23:38, 4 июня 2010 г. (UTC)
- Быстрые предложения и вопросы, учитывающие все моменты:
- У нас уже есть различные инструменты ( откат , IPBE ), которые могут использовать все администраторы и любой пользователь, одобренный администратором. Легкий процесс и для них. В качестве быстрого ярлыка для пробной версии предоставьте инструмент всем участникам отката - просмотр, как откат, требует разумной, но не чрезмерной степени доверия и понимания, и это будет означать, что инструмент запускается с значительным количеством пользователей, которые уже получили одобрение администратора. для инструмента, требующего аналогичных качеств.
- Мы также можем (для пробных целей) автоматически добавлять пользователей, которые кажутся заслуживающими доверия в целом или имеют приличный опыт, достаточный для обнаружения обычного вандализма и тому подобного. Например, пользователи, имеющие более 4 месяцев 100 правок в месяц или 1000 правок за последний год и не имеющие журнала блокировок ( довольно активные текущие пользователи, которые вносят существенное и последовательное редактирование, но не столкнулись с проблемами ). Мы могли бы сравнить их действия с действиями специалистов по откату и администраторов, чтобы понять, насколько деликатен контроль качества - ослабить его, если эта группа работает хорошо, сделать это «только по запросу», если из нее есть существенные неподходящие рецензенты. Число будет достаточно большим, чтобы его можно было использовать, и достаточно маленьким, чтобы избежать серьезных проблем.
- Мы могли бы в значительной степени вставить / отредактировать WP: ROLLBACK в качестве руководства по получению инструмента.
- Учитывая, что затронутые статьи составляют меньшинство, большинство автоподтвержденных не попадут в них или попадут в меньшинство своих правок. (Если это изменится в будущем, у нас будет время подготовиться.) Итак, вопрос в том, когда пользователь, не имеющий прав рецензента, попадает на такую страницу, как мы хотим это объяснить? Я за простоту: на этой странице есть небольшая задержка с публикацией ее правок, чтобы учесть (антивандализм патрулирование | проверка на вандализм). Ваши правки сразу же видны другим вошедшим в систему редакторам, пока это происходит. Если у вас есть чистая запись редактирования и разумный опыт, и хотят , чтобы утвердить ожидающие изменения самостоятельно, пожалуйста , посетите здесь .
- Q1 - существуют ли особые виды статей, которые испытание должно попытаться охватить, такие как продолжающийся вандализм над загруженными статьями, последние новости, громкие BLP / компании, низкопрофильные, но вандализированные / редактирующие подозрительные BLP, постоянные цели, долгосрочные защищенные страницы, обсуждение / обсуждение пользователя / споры на странице проекта, пространства имен, не относящиеся к статьям, и т. д.? Можем ли мы составить список областей с дополнительной ценностью для целей тестирования.
- Q2 - как будет обеспечиваться "относительно небольшое количество" страниц? Достаточно ли просто установить ограничение жесткого кода не более X страниц в любое время? или ограничение на количество новых страниц, добавляемых в систему (50 - 100 в день)?
- Q3 - какие коммуникации нам нужно будет создать для редакторов IP? Новые / неподтвержденные автоматически? Где нам общаться? Какие шаблоны могут понадобиться в качестве переходной меры?
- Надеюсь, это именно то, о чем вы просите. FT2 ( Обсуждение | электронная почта ) 00:21, 5 июня 2010 г. (UTC)
- Привет, FT2, вот несколько ответов с моей точки зрения:
- Q1 - С оперативной точки зрения было бы неплохо получить разнообразный набор статей (некоторые с тяжелым редактированием, некоторые с легким редактированием, некоторые с большим трафиком, некоторые с низким). Я добавил в Википедию новый раздел : «Помеченная защита и патрулированные версии» / «Пробная версия» с уточнением. Любой здесь должен быть свободен взять на себя инициативу по заполнению этого раздела.
- Q2 - краткий ответ: 2000 статей, ограниченных переменной конфигурации. Более длинный ответ: Википедия: Защита с пометкой и патрулируемые версии / Пробная версия # Пределы начального количества статей
- Q3 - Отличный вопрос. Я полагаю, что все они будут создаваться по запросу, но было бы неплохо воспользоваться этим. Вот с чего бы я начал: Помощь: Незавершенные изменения .
- Спасибо, что нырнули сюда! - RobLa ( разговор ) 00:51, 5 июня 2010 г. (UTC)
- Привет, FT2, вот несколько ответов с моей точки зрения:
- Начал там, как вы предложили, спасибо. Иди читай. Мне приходилось угадывать многие ожидаемые сроки и тому подобное. Кто-то, знакомый с предлагаемой реализацией enwiki, должен ее просмотреть и проверить, что именно одобрило это сообщество, и обновить страницу, чтобы правильно отразить это, и т. Д. Я предположил, что это также будет страница, прочитанная внешними рецензентами из СМИ, поскольку ну, и читатели, не являющиеся редакторами, поэтому он должен объяснить, что это такое , что это не так и почему. FT2 ( Обсуждение | электронная почта ) 02:34, 5 июня 2010 г. (UTC)
- Привет, FT2, это отличное начало, спасибо! Я прокомментирую больше в Help talk: ожидающие изменения и, возможно, начну вносить правки, которые я задумал. - RobLa ( разговор ) 03:52, 5 июня 2010 г. (UTC)
- RobLa: Дело в том, что мы решили, как мы этого хотим, и попросили реализовать это. Пожалуйста, реализуйте то, о чем мы просили. Это действительно так просто. ++ Lar : t / c 18:32, 5 июня 2010 г. (UTC)
- Привет, Лар, для нас (и для всех) важно понять, почему группа ручных репортеров так важна, а не только это важно. Например, в разговоре о помощи: процесс проверки ожидающих изменений , FT2 спрашивает: «Существуют ли ситуации, когда инструмент может быть использован недобросовестно, учитывая, что это только утвердительный инструмент (а не ограничивающий), другие пользователи также могут проверить, нет обязанность что-либо проверять и т. д.? ». Не могли бы вы (или кто-то здесь) объяснить это? - RobLa ( разговор ) 18:43, 6 июня 2010 г. (UTC)
- RobLa, я не уверен, что правильно понимаю вопрос. Если вы хотите знать, почему ручной рецензент важен, вам необходимо изучить множество страниц обсуждения, которые привели к консенсусу, что это часть требования, и попросить каждого из участников изложить свои взгляды. Но более того, я не уверен, что понимаю, почему вы задаете этот вопрос. Вы спрашиваете, чтобы усовершенствовать вашу разработку в соответствии с требованиями? Если да, то отлично, хотя уже немного поздно, не правда ли? Или вы просите, чтобы оспорить требование? Если так, то я думаю, что здесь все еще есть путаница в отношении того, откуда исходит направление. ++ Lar : t / c 00:21, 7 июня 2010 г. (UTC)
- Лар, я спрашиваю по двум причинам:
- Мы хотели бы убедиться, что обоснование где-то четко объяснено. Несмотря на то, что вокруг есть страницы для обсуждения, я надеюсь, что кто-то сможет четко, кратко и убедительно указать причину, которая не предполагает слова «говорил об этом, извините» .
- Есть еще несколько важных нерешенных пунктов политики, которые вам всем нужно решить, например, какие на самом деле будут пороговые значения. Например, на странице « Справка: процесс рассмотрения ожидающих изменений» по- прежнему указано, что порогом для того, чтобы стать пользователем, является «уровень редактирования ___ + правок в месяц в течение некоторых ___ месяцев». Следовательно, для фактического определения уровней важно обоснование наличия ручной группы. Говоря с моей шляпой WMF: мы не так озабочены тем, что такое уровни, так это то, что уровни были определены и четко переданы.
- Итак, почему так важна ручная группа пользователей? - RobLa ( разговор ) 23:29, 7 июня 2010 г. (UTC)
- Я все еще не понимаю, почему вы спрашиваете об этом. И почему именно сейчас . Таковы требования, и они выполняются какое-то время. Но, я думаю, я вас посмею, не признавая, что на самом деле вам следует спросить. Начнем со второго пункта. Откат проводился без четкого набора критериев, кто именно получил его. Тем не менее критерии эволюционировали в короткие сроки. Кто именно получит рецензента, не нужно решать заранее, решено навсегда. Он будет развиваться. Очень просто. По первому пункту, помимо того факта, что это то, чего хочет большинство, нет, консенсус сторон, я бы перевернул его и спросил вас ... как, черт возьми, вы могли бы подумать, что 10 правок за 4 дня (и ни одно человеческое проверять что угодно!) было бы достаточно, чтобы показать, что кто-то был способен правильно решить, что следует утверждать, а что нет? Смысл этой новой технологии - уменьшить воздействие вандализма. Если у нас есть вандалы, утверждающие правки, у нас беспорядок, а не исправление. ++ Lar : t / c 01:45, 8 июня 2010 г. (UTC)
- Лар, я спрашиваю по двум причинам:
- RobLa, я не уверен, что правильно понимаю вопрос. Если вы хотите знать, почему ручной рецензент важен, вам необходимо изучить множество страниц обсуждения, которые привели к консенсусу, что это часть требования, и попросить каждого из участников изложить свои взгляды. Но более того, я не уверен, что понимаю, почему вы задаете этот вопрос. Вы спрашиваете, чтобы усовершенствовать вашу разработку в соответствии с требованиями? Если да, то отлично, хотя уже немного поздно, не правда ли? Или вы просите, чтобы оспорить требование? Если так, то я думаю, что здесь все еще есть путаница в отношении того, откуда исходит направление. ++ Lar : t / c 00:21, 7 июня 2010 г. (UTC)
- Привет, Лар, для нас (и для всех) важно понять, почему группа ручных репортеров так важна, а не только это важно. Например, в разговоре о помощи: процесс проверки ожидающих изменений , FT2 спрашивает: «Существуют ли ситуации, когда инструмент может быть использован недобросовестно, учитывая, что это только утвердительный инструмент (а не ограничивающий), другие пользователи также могут проверить, нет обязанность что-либо проверять и т. д.? ». Не могли бы вы (или кто-то здесь) объяснить это? - RobLa ( разговор ) 18:43, 6 июня 2010 г. (UTC)
- Почему WMF заботится ? До сих пор процесс для подобных вещей прошел 1) Сообщество достигло консенсуса 2) Сообщество делает запрос 3) WMF проверяет наличие чего-то, что выглядит как консенсус, и реализует его. Почему WMF пытается вмешаться в это дело настолько активно, что оказывает то, что я могу описать только как сопротивление? Достаточно сложно сделать предложение, которое примет сообщество, если WMF тоже должен быть удовлетворен этим (а не просто удовлетворяться тем, что сообщество удовлетворено), мы никогда ничего не добьемся. Тем более, что сообществу в целом не нравится конкретика в предложениях, а WMF, похоже, на них настаивает. Г-н З- Ман 03:30, 8 июня 2010 г. (UTC)
- Пер Лар полностью объясняет, почему сообщество хочет, чтобы группа была предоставлена вручную, и о праве сообщества достичь консенсуса таким образом . Чтобы ответить на ваш другой вопрос, если WMF предоставляет версию «ожидающих изменений», в которой право рецензента предоставляется всем администраторам, и любой администратор может передать его неадминистраторам, это решает эту проблему. Такая же базовая конфигурация, как откат и исключение IP-блока. Сообщество может взять это оттуда, так как это ожидаемая конфигурация. Единственное, что, возможно, стоит сделать после этого, - это быстрая общая проверка, следует ли считать, что какой-либо компонент отката имеет доверие, необходимое для инструмента (для первоначального предоставления большой группы рецензентов). Но в любом случае это не вызывает споров и является проблемой сообщества. FT2 ( Обсуждение | электронная почта ) 11:59, 8 июня 2010 г. (UTC)
- Как я предлагал в другом месте, если мы будем медленно и контролируемым образом увеличивать количество статей, защищенных флагами, я уверен, что мы сможем сохранить минимальное количество статей с непроверенными исправлениями, даже если группа рецензентов начнет работу. пусто и заполняется вручную.
Я бы посоветовал создать где-нибудь страницу с очередью статей, которую мы хотим использовать для пробной версии, и каждый день в течение 30 дней 50 статей из верхней части очереди переключаются на флаговую защиту. Амальтея 13:35, 8 июня 2010 г. (UTC)
- Как я предлагал в другом месте, если мы будем медленно и контролируемым образом увеличивать количество статей, защищенных флагами, я уверен, что мы сможем сохранить минимальное количество статей с непроверенными исправлениями, даже если группа рецензентов начнет работу. пусто и заполняется вручную.
- Пер Лар полностью объясняет, почему сообщество хочет, чтобы группа была предоставлена вручную, и о праве сообщества достичь консенсуса таким образом . Чтобы ответить на ваш другой вопрос, если WMF предоставляет версию «ожидающих изменений», в которой право рецензента предоставляется всем администраторам, и любой администратор может передать его неадминистраторам, это решает эту проблему. Такая же базовая конфигурация, как откат и исключение IP-блока. Сообщество может взять это оттуда, так как это ожидаемая конфигурация. Единственное, что, возможно, стоит сделать после этого, - это быстрая общая проверка, следует ли считать, что какой-либо компонент отката имеет доверие, необходимое для инструмента (для первоначального предоставления большой группы рецензентов). Но в любом случае это не вызывает споров и является проблемой сообщества. FT2 ( Обсуждение | электронная почта ) 11:59, 8 июня 2010 г. (UTC)
- Упущен важный нюанс. В тексте уже отмечается, что он может быть удален «в случае серьезного или неоднократного неправильного использования». Возникает вопрос, существуют ли какие-либо другие обстоятельства, при которых «плохое использование» не было проблемой, но использование все еще было неприемлемым. Поддерживать вандализм было бы "неэффективным использованием", это прикрыто. Единственная ситуация, о которой я могу думать, - это когда пользователь правильно использует инструмент, но последовательно принимает точку зрения одной стороны в дебатах (хотя другая сторона вносит приемлемые изменения), чтобы «подтолкнуть» точку зрения этой стороны в глаза общественности. больше времени. FT2 ( Обсуждение | электронная почта ) 19:33, 6 июня 2010 г. (UTC)
Не уверен, что это подходящее место, но могут ли права рецензента быть привязаны к откату? Если бы в Huggle можно было что-то встроить, чтобы уведомлять вас о просмотре изменений в отмеченной статье, и вы могли бы отметить их как рассмотренные через интерфейс, я не думаю, что у нас будет много проблем с рассмотрением ожидающих изменений. Обратной стороной, конечно же, является поспешность, связанная с объятиями, но я думаю, что это было бы полезным способом проверить это. Есть достаточно большая группа специалистов по откату, и они в любом случае делают то же самое - в каком-то смысле это просто положительный способ одобрения хороших правок, а не отката вандализма. Однако, как средство отката без других флагов, у меня есть COI. {{ Соня | пинг | enlist }} 22:05, 6 июня 2010 г. (UTC)
- Интересная идея, но я думаю, что от нее уже отказались. Откат вандализма и просмотр правок - это две разные функции. Не возражаю против того, чтобы вещи были связаны с такими инструментами, как Huggle, с некоторой мыслью, но я не уверен, что существует одобрение, чтобы связать две функции / разрешения вместе. ++ Lar : t / c 00:21, 7 июня 2010 г. (UTC)
Страница пробной версии вернулась к исходной таблице
Я изменил Википедию: помеченная защита и патрулированные версии / пробная версия, чтобы соответствовать тому, что есть в Википедии: помеченная защита и патрулируемые версии (и соответствующие текущему состоянию дел на flaggedrevs.labs.wikimedia.org) и текущий план заключается в том, чтобы реализовать именно это. Мне еще нужно поработать над таблицей, чтобы (надеюсь) прояснить уровни защиты, но это будет чистое разъяснение, а не изменение. - RobLa ( разговор ) 22:48, 7 июня 2010 г. (UTC)
- Мне это кажется неправильным, похоже, это не соответствует требованиям, как я их понимаю. В частности, «В течение пробного периода у сообщества будет возможность обсудить возможность добавления нового уровня доступа к учетной записи для« рецензентов », который будет новым уровнем между« администратором »и« автоматически подтвержденным »пользователем. См. Википедия: Рецензенты для большего." похоже, предполагает, что создание группы рецензентов все еще остается предметом обсуждения. Насколько я знаю, это не обсуждается. И что означают два отмеченных уровня защиты? Оба ли настраиваемых состояния статьи? ++ Lar : t / c 01:45, 8 июня 2010 г. (UTC)
- Я исправил прозу, и теперь она гласит: «Группа« Рецензенты »- это новая группа, в которую пользователи со средним уровнем опыта редактирования могут запросить членство. Подробнее см. Википедия: Рецензенты ». Если на основании того, что вы знаете, есть еще что-то подобное, вы точно знаете, что это неправильно, не стесняйтесь менять это напрямую.
- Что касается двух разных уровней, то вот как сайт flaggedrevs.labs был настроен уже довольно давно. Именование уровней было моим дополнением, так как было действительно запутанно не иметь имен, но не стесняйтесь предлагать (или просто изменять) новые имена. Мне безразлично, как мы их называем, пока у нас есть имя для каждого. Может возникнуть некоторая путаница, потому что исходное предложение предусматривало три разных уровня , но мы недавно согласовали с текущей конфигурацией . - RobLa ( разговор ) 21:26, 8 июня 2010 г. (UTC)
- Спасибо за исправления и прояснение этого вопроса. ++ Lar : t / c 10:50, 9 июня 2010 г. (UTC)
Итак, этот вопрос решен. Спасибо, Кенарий ( разговор ) 14:44, 9 июня 2010 (UTC)
Просмотр помеченных исправлений Wikiproject
Я поднял этот вопрос в паре других мест и так и не получил ответа. Итак, сможем ли мы просматривать ожидающие изменения Википроектом правки? Мне не интересно просматривать все ожидающие изменения, только те, которые относятся к моей предметной области. Док Джеймс ( обсуждение · вклад · электронная почта ) 03:44, 11 июня 2010 г. (UTC)
- Я считаю, что не напрямую через пользовательский интерфейс ( Special: Unreviewedpages ). Однако создать бота, который будет делать это через API , несложно . MER-C 12:03, 11 июня 2010 г. (UTC)
- В этой реализации нет Special: Unreviewedpages, поскольку ни одна страница не имеет включенных ожидающих изменений без предварительной защиты, которая автоматически проверяет текущую версию. Специальная страница - Special: Oldreviewedpages , которую можно фильтровать по категориям. Кенарий ( разговор ) 19:27, 11 июня 2010 (UTC)
Подготовка
Учитывая, что это, вероятно, будет запущено через 3-4 дня, было опубликовано несколько сообщений, призывающих к созданию политик, уведомлений и т.п. Я попробовал некоторые из них, не вызывая противоречий.
Я рискнул и обновил политику защиты страниц и запросы, чтобы охватить ожидающие изменения. Причины: 1 / у нас не настроены страницы процессов, 2 / утверждение нового процесса для совершенно нового процесса хаотично, 3 / текущая политика защиты и запросы достаточно близки, чтобы быть принятыми для многих из них, 4 / одна цель состоит в том, чтобы пробное использование его вместо долгосрочной защиты, и 5 / это немедленно переносит это в «сферы привычного» для всех, кто уже использует защиту, вместо того, чтобы создавать целые новые процессы и страницы.
Поэтому я добавил его как «защиту от ожидающих изменений», и он отлично сочетается с защитой от перемещения, защитой создания страниц и защитой страницы.
- Википедия: Политика защиты ( примечание · правки )
- Википедия: Запросы на защиту страницы ( примечание · правки ) .
- Примечание на WP: AN # Ожидается судебное разбирательство по внесению изменений!
- Примечание к шаблону: Cent
Это позволяет значительно упростить запуск отложенных изменений, потому что это дополнительный инструмент защиты, а не множество новых вещей. Я делаю резюме AN, а затем мне нужно бежать на день.
Что я могу придумать, что необходимо дальше в порядке важности: 1a / шаблоны, подходящие для RFPP и тегов страниц, 1b / переписывание WP: PEND , 2 / обзор ключевых "живых" страниц с вопроса "покрывают ли они это должным образом "перспектива" и 3 / тегирование всех неактивных страниц с пометкой Rev. как "исторические" (во избежание путаницы). Добровольцы? Я работаю и уезжаю до воскресенья. FT2 ( Обсуждение | электронная почта ) 13:21, 11 июня 2010 г. (UTC)
- Я предлагаю использовать WP: Pending changes в качестве страницы для пробной политики. Сейчас я начну редактировать его с этой целью. Кенарий ( разговор ) 16:14, 11 июня 2010 (UTC)
Нам понадобится Википедия: ожидающие изменения, утвержденные в качестве политики для пробной версии, и Википедия: проверка ожидающих изменений, утвержденная в качестве руководства. Кенарий ( разговор ) 18:11, 12 июня 2010 (UTC)
- Я думаю, что этот RFC можно закрыть, а обсуждения перенести в другое место. Кенарий ( разговор ) 22:26, 13 июня 2010 (UTC)
- Закрыто. Кенарий ( разговор ) 07:52, 14 июня 2010 (UTC)
Заметки
- ^ http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolled_revisions/Trial#Simplified_protection_levels_for_the_trial
- ^ http://lists.wikimedia.org/pipermail/wikien-l/2010-May/106709.html
- ^ Это была оригинальная версия помеченной защиты, обсуждаемая здесь , консенсус не найден и отклонен в пользу новой версии.
- ^ Автопродвижение рецензентов и, тем более, предоставление прав на рецензирование всем автоподтвержденным пользователям, отклоненным на лекции Википедии: Рецензенты # Новое обсуждение и опрос: критерии рецензента .
- ^ http://en.wikipedia.org/w/index.php?title=Wikipedia:Flagged_protection&diff=268633713&oldid=268493293