This page is a translated version of the page Article validation and the translation is 100% complete.

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

Наразі єдиним механізмом «валідації» є модель відкритої вікі, яка дозволяє користувачам змінювати, адаптувати, реформувати або скасовувати зміни, внесені під час попереднього редагування.

Модель вікі є синонімом відкритості, тобто такої, де коригувальні заходи є постактивними (виконуються після факту), і хоча модель вікі призвела до значного успіху у створенні енциклопедії з нуля, зростання проєкту перевищило розмір його основної редакції, а в суперечливих областях розглядалося як перешкода для створення «стабільної» або «професійної» енциклопедії.

По суті, валідація — це план переходу до впровадження функціонального механізму, який змінить спосіб дії Вікіпедії від ідеалістичної концепції повністю відкритої моделі та надасть важливий інструмент, за допомогою якого довірені редактори можуть отримувати механічну допомогу у відбитті вандалізму. Оскільки така зміна теоретично може вплинути на саму філософію, завдяки якій Вікіпедія досі досягла успіху, необхідно, щоб такий механізм був добре продуманим, відкрито виправленим та ретельно поясненим.‎

=== Функція перевірки статей===‎

Ця функція є у MediaWiki 1.5 і очікується, що вона буде доступна у Вікіпедії у версії 1.5. Див. також Можливі проблеми перевірки статей.‎

Поточна ситуація

===Вікі Фонду Вікімедіа===‎

Отримувати облікові записи можуть лише користувачі, схвалені радою. Див. Запит на обліковий запис у вікі Фонду. Незатверджені або чернетки редагувань зберігаються на Meta.‎

Інші вікі

Інші вікі не мають систем затвердження, які впливають на редагування або зовнішній вигляд версій, але мають деякі заходи контролю якості (рецензування, вибрані статті, списки заглушок/підзаглушок тощо).‎

На деякі з них є посилання, серед іншого, з проєктів Вікімедіа.‎

HTML обмеження

Вікі Фонду дозволяє повне використання HTML. Інші вікі дозволяють обмежене використання HTML, як зазвичай робить MediaWiki software.

Загальні проблеми

Заявки

По суті, перевірку статей можна використовувати для трьох речей:

вікі Фонду
інші websites
статичні публікації (наприклад, paper, CDs/DVD, WikiReader)

Для цього можна використовувати подібні або різні системи перевірки.

====Вікі Фонд====‎

Вікі Фонд працює по-іншому, тому що:‎

Це дозволяє повне використання HTML
Все на цій вікі є офіційним. ---Daniel Mayer 16:28, 17 лютого 2005 (UTC)‎
Але деякі речі в інших вікі є офіційними і не захищені. Brian j d 03:11, 23 лютого 2005 (UTC)‎

Насправді, я не впевнений, що все на цій вікі є офіційним. Чи є сторінки обговорення офіційними? Brian j d 02:57, 24 лютого 2005 (UTC)‎
Ви плутаєте це питання. Фонд зобов'язаний дотримуватися заяв, зроблених на вікі Фонду. Користувачі тут не зобов'язані дотримуватися заяв, зроблених на Вікі. (За винятком сторінок політики тощо.) Без чіткого визначення того, що ви маєте на увазі під "офіційним", ці дебати не мають сенсу. Grendelkhan 20:20, 12 квітня 2005 (UTC)‎

=====Чому Meta не слід використовувати для непідтверджених або чернеткових редагувань=====‎

Таким чином, існує дві версії кожної сторінки:
- Обидві версії потрібно перевіряти, щоб отримати останню версію.
- Версії потрібно регулярно синхронізувати.
- Історія сторінки знаходиться у двох місцях.
Meta-версія може відображатися неправильно, тому що:
- вона не може використовувати HTML однаково (див. вище), та
- вона не має всіх шаблонів.
Вона розсилає останні зміни.‎

====Статичний контент====‎

Ми почали створювати статичний контент (див. наші WikiReaders). Коли розповсюджується статичний контент (CD-ROM, папір, PDF), помилка, що відображається в документі, не може бути виправлена читачем і залишатиметься видимою...назавжди... Це може негативно вплинути на публічний імідж Вікімедіа та поставити під сумнів достовірність усього нашого контенту.‎

Це, здається, вказує на те, що будь-який контент, офіційно розповсюджений Вікімедіа, повинен бути ретельно рецензований або мати чітке повідомлення, що вказує на характер контенту (прийняття внесків від будь-кого).‎

З іншого боку, інший статичний контент містить помилки, і репутація видавців, як правило, не заплямована.‎

HTML

Чи хочемо ми обмежити використання HTML за замовчуванням? Див. обговорення в англійській Вікіпедії. Brian j d 03:25, 6 березня 2005 (UTC)‎

Вандалізм

Деякі читачі стурбовані достовірністю нашого контенту, який часом спотворюється вандалами.

Мені здається, що це питання відрізняється від достовірності. Одне — злочинність, інше — точність чи ефективність.

Краще рецензування може збільшити нашу аудиторію та покращити нашу репутацію.
Перевірка статей може допомогти запобігти виявленню вандалізму та вказати, чи є вміст статті вандалізмом чи ні. :А може й ні. Хіба немає великої різниці між перевіркою та видаленням вандалізму? Переважна більшість випадків вандалізму дуже очевидна, і будь-який редактор може з нею впоратися.
Перевірка статей може розглядатися як виклик і тому збільшує кількість випадків вандалізму.

База редакторів

Деякі потенційні редактори-експерти відмовляються редагувати, оскільки вважають, що їхній контент буде пошкоджено вандалами або неекспертами. Надання послуги перевірки може допомогти їм почуватися впевненіше в цьому процесі.
Деякі нинішні редактори можуть вирішити не брати участі, якщо процес ускладниться.
У добре розвинених вікі-проєктах у деяких областях зростає відчуття захисту. Група редакторів іноді формує команду захисту, агресивно скасовуючи або редагуючи будь-які зміни, які їм не подобаються, тим самим запобігаючи природному розвитку процесу вікі. Надання їм впевненості в тому, що доступна хоча б одна схвалена версія, може допомогти їм бути більш лагідними з новачками або з редакторами, які мають інші упередження, ніж вони. *:Га? Якісь приклади? Чому з цими користувачами не розмовляють, або, якщо вони не реагують на це, їх блокують? Brian j d | Навіщо обмежувати HTML? | 08:33, 20 березня 2005 (UTC)‎

Версії

Захист перешкоджає/запобігає редагуванню та не є вікі-подібним. Див. Собор і базар, есе Еріка С. Реймонда. :Собор і базар абсолютно не має відношення до Вікіпедії. Програма з відкритим кодом зазвичай має одного або кількох розробників, які приймають хороші внески, відхиляють погані, випускають стабільні версії і яким не потрібно розгалужувати весь всесвіт, щоб їхній варіант окремої програми став широко використовуваним. Якби програмне забезпечення з відкритим кодом було "вікі-подібним", це була б катастрофа. -- Mpt, 2005-12-18‎
Усі версії наразі не можна редагувати та видаляти. Можна створювати лише нові версії.‎
Немає потреби приховувати найновішу версію від глядачів.‎

Переваги

Переваги описаного механізму затвердження очевидні та численні:

Ми заохочуватимемо створення дійсно хорошого контенту.
Це спрощує збір найкращих статей у вікі та створення їх завершених «знімків», які можна друкувати та розповсюджувати, наприклад. «Це питання є центральним для Pushing to 1.0.»‎

Недоліки

Люди можуть не захотіти робити невеликі внески, якщо вважають, що очікуються добре написані статті з посиланнями.‎
Механізм затвердження, орієнтований на експертів, можна вважати ієрархічною методологією, на відміну від проєктів з відкритим кодом типу bazaar, таких як Wikipedia, які, як відомо, досягають хороших результатів (наприклад, Linux) завдяки агресивному рецензуванню та відкритості (за достатньої кількості очних яблук усі помилки є поверхневими.). Можна стверджувати, що «сама причина», чому Linux став таким надійним, полягає в радикальному прийнятті, а певною мірою й повазі до роботи аматорів та ентузіастів усіх видів. (Примітка: Цей аргумент наразі дещо зворотний – код не потрапляє до ядра Linux, якщо патч не схвалений Лінусом Торвальдсом, а Лінус, ймовірно, прийме патч лише за умови попереднього схвалення відповідними розробниками підсистеми. Усі патчі повинні фактично функціонувати так, як заявлено, а також перевірятися на відповідність стандартам кодування. Постачальники Linux застосовують власний контроль якості до патчів, які вони включають у свої розподілені ядра. Якщо Вікіпедія хоче моделювати себе за зразком Linux, потрібно розуміти, що розробка Linux не є безкоштовною – потенційні внески ретельно перевіряються перед прийняттям)
Експерти мають суперечки між собою: наприклад, багато предметів у медицині та психології є предметом активних дискусій. Надаючи професору повну свободу у вирішенні питання про те, чи є стаття «схваленою» чи «не схваленою», існує ризик поставити під загрозу стандарти NPOV через те, що експерти надмірно наголошуватимуть на своїх конкретних думках та галузі досліджень.‎
Пошук експерта, який відповідає певній статті, іноді може бути проблематичним:
- Чи може доктор філософії з прикладної математики «схвалити» статті з чистої математики?, або, точніше, чи слід приймати когось як схвалювача лише за умови, що він/вона провів/провела дослідження з конкретної теми, яку він/вона схвалює? Хто вирішить, чи має людина право на схвалення?
- Деякі маловідомі або повсякденні теми не мають безпосереднього «експерта», пов’язаного з ними. Хто схвалить статті про хобі, ігри, місцеву культуру тощо?‎
Перевірка передбачає «необхідність» зазначення прийняття статті. Протилежне може більше відповідати поточній стратегії Вікіпедії – «відхилення» версій, які є неприйнятними. У більшості випадків відхилення взагалі не потребує експертів.
Експерти неминуче рідкісні. Це означає, що кількість людей, придатних для перевірки статей, невелика, і це питання масштабованості. Вікіпедія величезна, тому масштабованість дуже важлива. Іншими словами, немає сенсу мати механізм перевірки, якщо нічого ніколи не перевіряється (див. Nupedia).

Чи це потрібно?

Ось аргументи, чому додатковий механізм затвердження не потрібен для Фонду Вікімедіа вікі:

Вони вже мають механізм затвердження; хоча будь-хто може редагувати будь-яку сторінку, а експерти та аматори всіх рівнів можуть be bound та робити внесок у статті, «спільна перевірка є механізмом схвалення, хоча й не таким централізовано контрольованим, як peer review.‎
Незважаючи на свою недосконалість, вони вже сприяють більш витонченому критичному підходу до «всіх» джерел інформації, ніж проста опора на «рецензовані» авторитети. Низькоякісні статті може легко розпізнати читач з певним досвідом читання Вікіпедії або без нього, застосовуючи деякі базові критичне мислення: **Стиль може здаватися упередженим, емоційним, погано написаним або просто незрозумілим.
- Загальні заяви, відсутність цитування, спекулятивні твердження: будь-яка критична людина буде обережною, надаючи занадто багато авторства такій статті.
- Історія статті показує значну частину зусиль та рецензій, які були вкладені в її написання, «хто» та «наскільки кваліфіковані» автори (користувачі, здається, розміщують деяку біографічну інформацію про себе на своїх сторінках).
- Досвідчений читач швидко дізнається, що сторінка «Обговорення» часто є повчальною щодо процесів, які призвели до поточного тексту статті.
Звірка з іншими джерелами є «надзвичайно» важливим принципом для якісного збору інформації в Інтернеті! Жодне джерело не слід вважати на 100% надійним.
Деякі «авторитетні» та «схвалені» енциклопедії, здається, не відстоюють власні претензії на достовірність. Див. помилки в Енциклопедії Британіка, які були виправлені у Вікіпедії.‎
Сама ідея «схвалення» статті є дискусійною, особливо на суперечливі теми, і дехто може розглядати її як недосяжний ідеал.‎

===Запропоновані основні вимоги===‎

Серед основних вимог, яким механізм схвалення повинен відповідати, щоб бути адекватним, є:‎

Схвалення має бути здійснене «експертами» щодо схваленого матеріалу. «модель довіри?»‎
Повинні бути чіткі та досить суворі стандарти, яких експерти повинні застосовувати.‎
Сам механізм має бути справді «легким» для використання або дотримання експертами. Досвід Nupedia показує, що складна процедура затвердження, хоча й може бути суворою, є занадто повільною для «практичного» використання.‎
Механізм затвердження «не повинен» жодним чином перешкоджати розвитку Вікіпедії. «Він не повинен змінювати процес wiki, а радше бути «додатком».‎
Не повинен заважати програми, і не повинен вимагати додаткового програмного забезпечення або покладатися на браузер-специфічні речі, такі як Java (або JavaScript), яких деякі користувачі не матимуть. «Для них має бути визначено спільний стандарт платформи браузера, бажано низького рівня, але не настільки низького рівня, щоб машини не мали компакт-дисків».
Повинен забезпечувати певний спосіб перевірки credentials експерта та, за бажанням, «спосіб перевірки того, що «він чи вона» схвалили статтю, а не самозванець».

Деякі результати, які ми можемо очікувати від системи схвалення, полягають у тому, щоб вона:

дозволяла розширювати або звужувати вибір осіб, які схвалюють (наприклад, одна людина може бажати мати лише авторів, які мають ступінь доктора філософії, інша дозволяла б будь-кому, хто доклав зусиль для схвалення будь-яких статей.),
забезпечувала основу для дозволу кількох наборів «схвалень», дозволяла не лише один набір «схвалювачів» або один «рейтинг схвалення», а різні набори, щоб враховувати різні стандарти. (Тобто, як і у випадку зі споживчими товарами, різні схвалення безпеки, сертифікати підводного плавання тощо)

Ось ще одна запропонована система:

Додайте «оцініть цю зміну!» функція програмного забезпечення. Будь-хто може оцінити будь-яку зміну за шкалою від -3 до 3, де -3 означає «забанити цю особу», -1 означає «невеликі помилки», 0 означає «немає думки», +1 означає «невелике покращення» та +3 означає «це чудовий внесок». Навіть оцінка 0 корисна, оскільки вона означатиме, що зміну було перевірено, і не було виявлено жодних грубих помилок чи саботажу.
Суть у тому, щоб просто почати збирати дані. Після того, як дані зібрано, має бути легко визначити систему рейтингу довіри на основі цих даних, і, ймовірно, будь-який розумний метод спрацює.

Визначення

механізм затвердження: механізм, за допомогою якого статті окремо позначаються та відображаються як "затверджені"

аспект валідності: один з наступних - точний (перевірений фактами), нейтральний (NPOV), добре написаний (перевірений на граматику, орфографію, правильний стиль, зрозумілий) та повний (висвітлення відповідає важливості теми)

рецензована версія: версія статті, якість якої була перевірена принаймні одним редактором (у кожному аспекті)

валідована версія: рецензована версія, якість якої підтверджена (кваліфікованим) користувачем на основі її змісту та видатних рецензій (хоча її сукупний рецензія не є негативною в жодному аспекті)

рецензована/перевірена стаття: стаття, принаймні одна з версій якої була перевірена/перевірена

публічна версія

версія статті, показана користувачам, які не ввійшли в систему

Публічна версія не обов'язково має відрізнятися від останньої відредагованої версії. Програмне забезпечення може посилатися на останню перевірену версію та позначати відмінності від неї кольором у відображеній версії.‎

кількість не повинна вимірюватися - Бург.

справді? Важливо, щоб наша стаття про Geology демонструвала глибину нашого відповідного контенту та належно відображала важливість широкої теми. Я погоджуюся, що оцінка повноти не повинна відбуватися в тій самій лінійній шкалі, що й оцінка правильності та якості написання. +sj+‎

Схоже, це було перенесено з Вікіпедії (Geology). Brian j d 05:39, 17 лютого 2005 (UTC)‎

Хто може перевірити?

створити комітет з перевірки (групу довірених, зацікавлених вікіпедистів) - потрібен окремий "доступ для перевірки" для тих, хто був схвалений для участі в цих комітетах з перевірки?‎
будь-який користувач або група користувачів, що відповідають певним статистичним вимогам (поєднання часу з моменту реєстрації, кількість редагувань статті, загальна кількість редагувань)‎
будь-який користувач або група користувачів
- Будь-який користувач, але перевірки різних користувачів коштують різну суму, залежно від показників довіри. (Я зараз проводжу додаткові дослідження з цього питання і напишу відповідь, якщо щось знайду.) Lbs6380 04:07, 14 лютого 2005 (UTC) --- Як обіцяв: мої ідеї. Не соромтеся копіювати їх сюди та експериментувати з ними.‎
Адміністратори (які є довіреними членами спільноти) та будь-який користувач, якого 3 адміністратори позначили як надійного.‎
автоматична перевірка:
- після того, як певна кількість (кваліфікованих?) користувачів відредагували статтю
- після того, як член певної групи відредагував статтю
- після того, як версія залишалася актуальною протягом певного часу (тому припускаючи, що попереднє редагування було легітимним, а не вандалізмом)‎
окремі обмеження перевірки для різних видів перевірки (наприклад, створення комітетів з перевірки фактів для кожної основної категорії, на основі досвіду/експертизи)‎

(Зауважте, що мало що з переліченого вище наразі стосується рівня знань «валідатора» про предмет, а лише його тривалості роботи чи здібностей до редагування вікі. Це може бути недоречним для деяких предметів --VampWillow 11:28, 5 грудня 2004 (UTC))‎

Як можна перевірити?

Перевірка за допомогою додаткових метаданих - дозволити користувачам додавати інформацію про різні аспекти статті та підсумуйте їх з точки зору того, чи була стаття перевірена і наскільки ретельно.‎
Перевірка комітетом - мати редакційну колегію, яка обирає тематичні комітети, що встановлюють єдиний прапорець «перевірено» на статтях після досягнення ними зрілості.‎
Зважування та усереднення рецензій - Вимагати супербільшості серед довірених рецензентів для ключових аспектів статей; використовувати приблизну метрику довіри, щоб зменшити вплив зловмисних рецензентів.‎

Запропонований процес перевірки

Див. Пропозиції щодо перевірки статей. Також, Позначені версії в англійській Вікіпедії.‎

Обговорення та пропозиції

Див. сторінку обговорення пропозицій щодо перевірки статей.

Інші пропозиції

Щоб переглянути сторінку Вікіпедії на цю тему, дивіться en:Wikipedia:WikiTrust та її сторінку talk.‎

Я почав писати метрика авторитетності як розділ цієї сторінки, але він став трохи довгим, тому я переніс його в окрему статтю. Будь ласка, перегляньте його, він тісно пов'язаний з обговоренням вище. -- Тім Старлінг 03:02, 17 листопада 2004 (UTC)‎

На мою скромну думку, перевірка на 90% є соціальною та на 10% технічною. Соціальна (або, якщо хочете, політична) частина — це «кому» ми довіряємо — яким людям або якій установі, що складається з людей — засвідчити, що стаття (станом на таку-то дату та час) є точною, повною чи щось таке?» Технічна частина полягає в тому, «як нам зберігати ці сертифікати в базі даних і повідомляти їх користувачам?» Я скромно пропоную рекомендацію статті як спосіб вирішення технічної частини. Sethg 16:31, 18 листопада 2004 (UTC)‎

Чому б не використовувати UCSC WikiTrust?? Він вже доступний як розширення MediaWiki та автоматично кодує редагування кольорами на основі показників довіри.

==Два типи пропозицій та їхній структурний зв'язок==‎

Пропонується два основні, абсолютно різні типи «перевірки статей».

Версії: Кожна стаття має одну «найкращу версію», яка називається «публічна версія» у розділі визначення вище. За неї голосують автори цієї статті (і, можливо, глядачі).
Статті: Підмножина статей вибирається як «рекомендовані статті», «рецензовані статті» або «перевірені статті». Вся спільнота (або її добровільна підмножина) голосує за кандидатів.

Ці дві різні структури не є взаємовиключними. Навпаки, вони добре працюють разом. Їх можна легко поєднати:

Підмножина публічних версій вибирається як «рекомендовані публічні версії» або «рецензовані публічні версії» або «перевірені публічні версії. Уся спільнота (або її добровільна підгрупа) голосує за кандидатів.

Єдина неоднозначність полягає в наступному: після того, як публічну версію статті обрано як рекомендовану/рецензовану/перевірену публічну версію, коли нова публічна версія вибирається авторами цієї статті, чи стає ця нова публічна версія новою рецензованою спільнотою публічною версією, чи її потрібно переномінувати? Я думаю, що її буде переноміновано.

З огляду на це, вибір спільнотою підгрупи публічних версій для перевірки не вимагає реалізації програмного забезпечення. Це вже чудово робиться на en через "вибрані статті".

Вибір публічної версії з історії статті (або деякі запропонували розгалуження, що можна зробити в процесі перевіреної публічної версії) "дійсно" вимагає програмної реалізації, і є набагато більше способів зробити це.

Враховуючи вищесказане, я вважаю, що обидва типи повинні бути реалізовані, але оскільки "публічна версія"

обов'язково передує перевіреній публічній версії,
вимагає програмної реалізації та
є більш відкритим питанням, "публічні версії" повинні бути в центрі уваги цих сторінок. Kevin Baas^talk 23:56, 8 квітня 2006 (UTC)‎

Підтримую, за винятком необхідності програмної реалізації. Ідентифікація публічних версій можлива за допомогою сторінок обговорення та простору імен Вікіпедії. - Samsara 09:51, 15 квітня 2006 (UTC)‎

Тоді дозвольте мені сказати, що за допомогою програмної реалізації це можна зробити «зі значно меншими зусиллями», і це не можна порушити чи обійти. Kevin Baas^talk 19:14, 16 квітня 2006 (UTC)‎