Це есе містить поради або погляди одного чи більше дописувачів Вікіпедії. Есе можуть відображати як широковизнані норми, так і переконання невеликої групи. Ставтеся до цих порад розважливо. Есе не є правилом чи настановою.
Розробка правил і настанов у Вікіпедії — найвищий рівень самоорганізації спільноти. Якщо спільнота здатна формалізувати, втілити у слова те, що йде на користь Проєкту, а що шкодить — це є ознакою високого рівня її розвитку. Якщо зовсім спрощувати, розробка правил — це формулювання що є Добром для Вікіпедії, а що — Злом.
Правила окреслюють межі дозволеного та задають напрямок, в якому буде розвиватися проєкт. Встановлені Фондом основні правила не підлягають обговоренню, і містять базові засади функціонування Вікіпедії. Будь-які додаткові правила, розроблені спільнотою, повинні або вирішувати постійні точки напруги у ній, або поліпшувати умови роботи дописувачів і працювати на розвиток Вікіпедії.
Це есе містить декілька загальних порад, які варто мати на увазі як при створенні правила з нуля, так і при внесенні невеликої поправки у готове правило. Якщо коротко:
докопайтеся до першопричини — вирішуйте тільки корінь проблеми, регулюючи його новим правилом. Переконайтеся, що ви не боретеся із симптомами.
знайте адресата правила — детальність норм та стиль викладу має відрізнятися залежно від призначення правила: чи воно адресовано здебільшого новачкам, чи досвідченим метапедистам. Правило має бути конкретнішим і прямішим, якщо адресоване перш за все новачкам.
потрібність — переконайтеся і доведіть іншим, що справді є потреба писати окреме правило.
перевірте альтернативи — розгляньте всі можливі альтернативні шляхи вирішення. Ідея правила, яку ви мали початково, може бути не найбільш оптимальною.
самоописовість — правило має хоча б у двох словах пояснювати яку проблему вирішує, щоб навіть новачок міг здогадатися звідкіля воно з'явилося і чому важливо його дотримуватися.
чітка спеціалізація — правило має регулювати тільки одну вікіпедійну тему, аспект, явище.
несуперечливість — правило не повинно мати проблем із внутрішньою логікою, і не суперечити решті правил і настанов Вікіпедії.
легкість у виконанні — правило має легко застосовуватися на практиці. Критерії мають просто перевірятися. Алгоритми і процедури мають бути прозорими.
Сам процес:
створіть окрему сторінку для пропонованого проєкту (якщо проєкт довший ніж одне речення чи короткий абзац).
додайте порівняльну табличку БУЛО → СТАЛО із показовими прикладами застосування — так учасникам обговорення буде простіше отримати уявлення як пропоновані зміни будуть виглядати на практиці.
почніть публічне обговорення.
здобудьте підсумок, навіть якщо це буде підсумок про відсутність консенсусу.
якщо одразу відсутня повна згода, затверджуйте правило поетапно, починаючи із ядра правила, з яким згодна переважна більшість. На наступних етапах обговоріть і проголосуйте більш суперечливі моменти.
Підготовка до розробки
Перш ніж сісти за безпосереднє написання правила і формулювання конкретних його норм, варто вирішити задачу першочергової важливості — чітко окреслити проблему, яку майбутнє правило буде вирішувати. Глибоке розуміння проблеми є ключовою складовою її вирішення. Головний підводний камінь під час її формулювання: прийняти тільки окремі симптоми певного негативного явища як проблему загалом. Вузький погляд на ситуацію призведе до того, що ви лікуватимете поверхневі симптоми, таким чином лише створюючи видимість вирішення. Подумайте про те, якої мети ви насправді хотіли б досягти в кінцевому результаті — можливо, це підкаже як поглянути на проблему більш широко, більш комплексно, або під іншим кутом.
Без етапу підготовки і окреслення проблеми, всі наступні можуть бути лише змарнованими зусиллями.
Отже:
чітко окресліть проблематику. Оформіть її як завершену думку. На цьому етапі це може бути справді тільки думка у вашій голові. Ви повинні сказати собі в чому полягає безпосередня проблема, яку ви збираєтеся вирішити написанням правила.
подумайте про інші шляхи вирішення. Можливо, ви поки бачите тільки один спосіб, в який можна вирішити проблему (власне, написанням цього правила), але варто докласти спеціальних зусиль, щоб самостійно подумати про можливі альтернативні способи.
не ремонтуйте не поламане. Вдосконалювати правила завжди доречно, проте треба спитати себе — чи справді варто витрачати зусилля для врегулювання мізерної чи й взагалі відсутньої проблеми? Будьте готові довести спільноті, що ви не ремонтуєте не поламане.
створіть обговорення у кнайпі: викладіть там вже обдуману і пропрацьовано самостійно проблему, і повідомте спільноті, які шляхи її вирішення ви бачите.
Буде добре, якщо спільнота включиться у обговорення вашої пропозиції. На цьому етапі можна отримати дуже цінні підказки і щодо проблематики, і щодо ймовірних шляхів її вирішення:
можливо, те негативне явище, яке ви спостерігаєте, має зовсім іншу природу — скоригуйте спільне бачення проблематики;
можливо, ту проблему, яку ви бачите, можна вирішити і не процесом написання і затвердження нового правила, а у якийсь інший спосіб;
.. а якщо й написанням правила, то не таким, яким ви бачили його на початку.
Написання правила
Коли проблематика була сформульована, час закріпити шляхи її вирішення на папері. Створюючи текст правила, пам'ятайте про такі речі:
правило має бути простим. Воно повинно і легко розумітися, і — що важливо — легко виконуватися. Подумайте про те, чи буде ним легко користуватися на практиці. Складні підрахунки, численні умови, логічні відгалудження та винятки — все це призведе до того, що користуватися правилом буде надзвичайно обтяжливо, а отже й користі воно не принесе.
правило має бути несуперечливим. Норми правила не мають суперечити одна одній — це призведе до суперечок і конфліктів в майбутньому, коли у користувачів виникнуть непопрозуміння щодо його трактовки.
правило має бути чітко сфокусованим. Воно повинно вирішувати ту, і тільки ту проблему, яку ви окреслили. Воно не має перетинатися з іншими правилами, дублювати їхні норми. Воно також не має вирішувати кілька слабко дотичних проблем, які вимагають різних вирішень — в такому випадку краще розділити правило на декілька. Правило буде незручним, якщо міститиме вимоги і рекомендації про кілька стратегій поведінки, або щодо кількох слабко пов'язаних між собою тем. Недосвідчений користувач може не згадати де він прочитав певну норму, бо заголовок правила з нею не пов'язаний.[1]
правило має бути лаконічним. Якщо є речення, фрази і слова, без яких можна обійтися — сміливо їх вилучайте.
правило має бути самоописовим. У гонитві за лаконічністю ви можете прийти до інших крайнощів: до ідеї писати правила лише як сухі машинні інструкції. Не робіть так. Правила мають у своєму тілі містити мінімально достатню кількість пояснень, щоб навіть людина без досвіду у Вікіпедії зрозуміла яку проблему це правило вирішує, і чому важливо дотримуватися прописаних у ньому норм.
розробляючи текст, пам'ятайте, що правила у Вікіпедії не пишуться заради правил. Правило має працювати на вдосконалення Вікіпедії, а не бути демонстрацією своїх умінь у написанні і узгодженні норм.
Якщо ви запроваджуєте якийсь критерій, він має бути легко перевірним. Намагайтеся прив'язуватися до таких критеріїв, де можна отримати чітку відповідь «так» або «ні» при його перевірці.
За можливості, уникайте критеріїв, побудованих на основі підрахунку певного параметру N (зробив N правок, пропрацював N років, обробив N погонних одиниць) — підбір конкретного числа N для цього параметра є за своєю природою цілковито невдячним зайняттям: підбирається абсолютно штучне, не продиктоване об'єктивною реальністю число. Суперечки навколо нього будуть неконструктивні за своєю природою. Замість підрахунку параметру N спробуйте знайти якусь іншу перевірку, яка б слугувала тій же меті, проте була б простішою.
Пояснювальний приклад:
Якщо стоїть задача запровадити критерій для перевірки досвіду або стажу особи, невдалою ідеєю був би критерій на кшталт 10 років у професії чи написав 100 статей. Підрахунок такого параметра може ускладнюватися ймовірними розривами у стажі, або питанням що вважати статтею, чи вважати кілька статей циклу однією роботою чи кількома, і на яких ресурсах статті достатньо бути опублікованою. Натомість, приблизно те ж завдання вирішували б більш прості для перевірки критерії, до прикладу:
особа обіймала посаду керівника департаменту певного рівня
особа була нагороджена відзнаками певного рівня у її галузі
робота особи (наукова праця, тощо) публікувалася у певному, справді поважному, галузевому виданні
На такі запитання можна отримати однозначне «так» або «ні», якщо вже знайдено консенсус щодо необхідного рівня департаменту, відзнаки, видання.
Може існувати система значущості, заснована на балах. Вона формалізує істотність висвітлення, чим знижує рівень різночитань до мінімуму щодо висвітлення. Цим суттєво скорочується «сіра зона» невизначеності правил.
Пояснювальний приклад:
Особа вважається значущою, якщо набирає мінімум 5 балів. По одному балу нараховується за: відома дата народження, місце народження, заклад здобуття освіти, місце роботи до або після війни, орден або медаль, належність військовому формуванню з точністю до фронту, участь у боях з точністю до міста. Тобто із 7 перерахованих вимог треба мати інформацію щонайменше про 5, що означатиме: є мінімально необхідне висвітлення.
Якщо розробляється правило, що має остаточно затвердити на майбутнє вжиток одного з двох варіантів: Варіант А або Варіант Б, спитайте себе — а чи тільки двома варіантами обмежений вибір? Чи існує Варіант В, Варіант Г? Якщо ж вибір справді відбувається лише між двома варіантами, то перевірте, чи можна замість протиставлення «або Варіант А, або Варіант Б» розробити правило, яке регулюватиме вжиток обох варіантів у вигляді: «За яких умов Варіант А, а за яких — Варіант Б?». Саме другий підхід у багатьох випадках може виявитися найбільш конструктивним.
Займаючись розробкою правила, не можна нехтувати досвідом інших мовних розділів Вікіпедії — вони могли вирішити проблему до вас, і вже оформити її вирішення у добре сформульоване правило. Тому вивчення їх досвіду — це економія часу і зусиль, а також крок до створення кращого правила.
Водночас, великою помилкою може бути дослівне копіювання норм з іншомовної Вікіпедії. Причини:
вони вирішували свої проблеми. Проблеми у іншомовній Вікіпедії, які вирішувалися запровадженням правила, — не завжди тотожні проблемам, з якими стикається Українська Вікіпедія. Власне, має бути перевірено, чи вирішує іншомовне правило окреслену на попередньому етапі проблематику. Чужий досвід має бути проаналізований, вивчений, і пропущений через актуальні для Української Вікіпедії проблеми, виклики і задачі. Немає жодної необхідності повторювати ті норми з іншомовномого правила, які регулюють певні нюанси, з якими Українська Вікіпедія не стикається.
іншомовне правило може бути недосконалим саме по собі. Воно може бути або застарілим, або містити певні вади і хиби від початку. Тільки те, що воно прийняте як правило в іншому мовному розділі, не є абсолютною гарантією його якості. Якщо ви використовуєте елементи іншомовного правила для написання власного, завжди робіть спроби поліпшити його — виписати його краще, ніж воно було в оригіналі.
Два прості кроки вирішують питання взаємодії з іншомовними правилами:
спершу самостійно, власноруч випишіть якомога детальніше проєкт правила. Вирішуйте ту задачу, яка перед вами стоїть. Обговоріть його зі спільнотою і врахуйте зауваження.
лише після власних докладених зусиль перечитайте іншомовні правила і запозичте лише найбільш вдалі норми і моменти, до яких вам не вдалося здогадатися самостійно. Ви не зможете ефективно відділити непотрібне і надлишкове для Української Вікіпедії від корисного і доречного, якщо почнете написання правила з перекладу іншомовного правила.
Двома словами:
Докладіть максимальних зусиль для самостійного вирішення вашої задачі, і лише потім звертайтеся до чужого досвіду.
Затвердження
Щоб правило запрацювало на користь спільноти, воно має бути спершу нею затверджене. Є кілька порад, яких варто дотримуватися на етапі затвердження правила:
Текст правила має бути на виду.
створіть для проєкту правила окрему сторінку. На сторінці проєкту має бути тільки текст правила, і нічого більше.
окремої сторінки можна не створювати для тих поправок у вже готові правила, які зачіпають лише одну норму, стосуються одного речення.
текст правила завжди має бути у найновішій версії. Ви будете вносити великі і малі правки, але користувачі мають бачити останню його версію — що вони зараз обговорюють, чи за що голосують.
все це також справедливо, якщо є декілька проєктів одного правила — кожен повинен мати окрему сторінку.
Додайте порівняльну табличку БУЛО → СТАЛО із показовими прикладами застосування.
Оберіть кілька найбільш показових або складних прикладів, що ілюструватимуть поточний стан і пропонований (або кілька пропонованих варіантів, якщо розглядається кілька конкуруючих проєктів). Так учасникам обговорення простіше буде отримати уявлення як пропоновані зміни будуть виглядати на практиці.
Спочатку обговоріть правило.
навіть якщо ви вже мали попередні обговорення про проблематику і шляхи вирішення, все ж прийняття конкретного тексту правила — це окрема задача.
створіть нову гілку у Вікіпедія:Кнайпа (політики) і повідомте спільноті про роботу над правилом, показавши його проєкт. Відведіть 3—7 днів тільки на обговорення проєкту тексту правила спільнотою.
обговорення проєкту бажано вести або у Вікіпедія:Кнайпа (політики), або на сторінці обговорення проєкту змін. У другому випадку уся дискусія щодо правила буде компактно зібрана на одній сторінці, і залишиться легко доступною на майбутнє.
вислухайте аргументи і зауваження. Врахуйте сильні аргументи, включивши їх до проєкту правила, і наведіть контраргументи для тих тез і зауважень, з якими ви не згодні.
Це — одна з найголовніших рекомендацій з усієї цієї сторінки.
Врахування сильних аргументів і спростування слабких — наріжний камінь у розробці правил. Ухвалення правил потребує дуже високої кваліфікації всіх учасників, тому що саме по собі ухвалення правил не нормоване іншими правилами. Це чисте випробування на логіку, здоровий глузд, знання традицій і проблем спільноти.
під час обговорення можуть сформуватися «табори опонентів» (як правило, два), що притримуються протилежних поглядів. Важливо зібрати докладну аргументацію обох груп: чому вони мають саме цю точку зору, бажано із «дистильованим» переліком аргументів і контраргументів. Етап збору «дистильованої» аргументації бажано зробити у підсумку (проміжному підсумку) — тоді іншим вікіпедистам не потрібно буде читати довгі простирадла обговорень із «водою», перепалками, офтопом.
не занепадайте духом, якщо спільнота практично не реагує на вже запропонований вами проєкт. Реакція буде, коли почнеться голосування щодо затвердження.
Підготуйте голосування.
коли завершилося попереднє обговорення, можна перейти до голосування.
пересвідчіться, що текст проєкту правила — на виду;
оголосіть строки — дати початку і закінчення голосування. Як правило, загальні голосування тривають щонайменше 7 днів. Якщо ви добре підготувалися, сумлінно виконавши попередні етапи, цього буде досить, щоб зрозуміти думку спільноти з приводу правила;
під час голосування не створюйте блоки За і Проти — це надмірно примітивізує процес обговорення. До того ж, користувач, який вже проголосував, може змінити свою думку у процесі, і найлегше буде, якщо він зможе відредагувати свій голос без перекидання своєї репліки з блоку в блок.
враховуйте зауваження під час голосування так само, як це було під час попереднього обговорення. Не вагайтеся вносити корективи до проєкту правила прямо на льоту, якщо вони справді резонні;
утримайтеся від спокуси включити до проєкту слабкі зауваження тільки для того, щоб здобути підтримку користувача у голосуванні. Наведіть натомість вагомі контраргументи, що пояснили б чому такі зауваження включити не можна;
Якщо під час обговорення чи голосування існує серйозна незгода щодо одного чи кількох моментів правила і ви не можете одразу на місці їх виправити, виключіть їх із проєкту. Ухваліть ту частину правила, щодо якої всі переважно згодні. Потім поверніться до суперечливих моментів, і розгляньте їх по одному, імовірно з окремим голосуванням щодо кожного.
Не намагайтеся протягувати щось «пакетно», тобто включити до корисного і потрібного правила вкрай суперечливі моменти: це не піде на користь нікому.
Тобто, розробка і затвердження правила може відбуватися поетапно. У найбільшій мірі це стосується великих правил — вони майже завжди повинні розроблятися поетапно: від ядра, щодо якого існує широка згода, до деталей, які мають бути обговорені окремо в наступних ітераціях прийняття.
Табори опонентів
Якщо у обговоренні сформувалися «табори» (як правило, два) із протилежними точками зору, і їх неможливо поєднати у рішення, що задовольнятиме обидві сторони (як При таких-то умовахВаріант А, а при таких-то умовахВаріант Б), докладіть зусиль для того, щоб формалізувати аргументацію обох таборів. Цей процес називається «дистиляцією», оскільки кожнен з таборів має представити остаточний варіант тексту правила, а також остаточно сформований набір аргументів і контраргументів що пояснюватимуть їхні позиції.
Кожен з таборів має самостійно вирішити які аргументи він вважає за сильні, а які ні. Можливо, для цього завдання кожен з таборів муситиме вирішити внутрішні протиріччя, щоб представити консолідовану, сильну позицію із найкращих аргументів. Не приписуйте протилежному табору того, що він не мав наувазі: демагогічний прийом зі створення солом'яного опудала, яке легко «перемогти», не допоможе вам знайти спільну мову із опонентами. Поважайте думку опонента, дослухайтеся що ж справді він вважає і за що бореться.
... рішення у Вікіпедії ухвалюються не за кількістю тих, що «зазирнули» й «проголосували», а на підставі представлених аргументів. Спроби зміни консенсусу повинні базуватися на ясному зіставленні, і колишньої аргументації, що лягла в основу наявного консенсусу, і нових аргументів. Саме тому в новому розділі сторінки обговорення необхідно представити резюме історії обговорень цього питання з посиланнями на попередні дискусії, що й дасть можливість новим учасникам дискусії ознайомитися з обґрунтуванням наявного консенсусу й ухвалити рішення, виходячи з максимально повної інформації. — Вікіпедія:Консенсус § «Тато заборонив, спробую запитати у мами» (про некоректні способи пошуку консенсусу)
Коли позиція обох таборів буде максимально точно відтворена, можна оголосити фінальне голосування, яке в результаті покладатиметься на просту більшість голосів. Учасники такого голосування матимуть чітко викладені аргументи обох таборів, а також таблицю прикладів БУЛО → СТАЛО для обох пропозицій. Тобто, за ВП:Консенсус матимуть якнайбільш повне уявлення, щоб голосувати усвідомлено. Без такої повно представленої аргументації обох сторін, тобто коли позиція однієї зі сторін не є цілком представленою, голосування може бути позбавленим змісту.
... найважливішим елементом вироблення консенсусу є впевненість у тому, що всі сторони вислухано й усі аргументи розглянуто ...
Для знаходження консенсусу потрібно ретельно оцінити силу та якість самих аргументів, наведених різними сторонами, і принагідно висловлених нюансів. [..] Тільки такий зважений підхід прийнятний для користувача, який зголошується зробити будь-які дії на підставі такого консенсусу, що складається.
Думки меншості, як правило, відображають суттєві аспекти питання, — і тому дискусія повинна ставити собі за мету досягнення найприйнятнішого компромісу.
...
Таким чином, ухвалення рішень у Вікіпедії не ґрунтується на формальному підрахунку голосів: Вікіпедія — не експеримент з демократії. Голосування чи опитування самі по собі не є основою для ухвалення рішень, — і ніхто не зобов'язаний підкорятися їх результатам, за винятком деяких особливих випадків, коли це зумовлено правилами. — Вікіпедія:Консенсус § Практика пошуку консенсусу
Втілення нового правила у життя
Якщо новозатверджене правило своїми нормами зачепить одразу значну кількість сторінок і статей, то проти його розробки і ухвалення можна почути такий аргумент:
— Це ж тепер прийдеться усе міняти й переробляти у статтях. Хто цим займатиметься? У нас і так рук не вистачає, а тепер ще це.
Цей аргумент не можна назвати вагомим проти затвердження правила, якщо воно справді корисне і потрібне: ніхто не зобов'язаний одразу втілити зміни у всіх статтях відповідно до новоприйнятої норми. Новозатверджене правило слугує для інших цілей:
бути орієнтиром для всієї спільноти при створенні нових статей або при врегулюванні всіх подальших ситуацій, для яких правило застосовне;
бути опорою для того користувача, який наводить лад у старих статтях. Якщо виникне суперечка чи конфлікт щодо цього впорядкування, користувач матиме затверджене правило як сильний аргумент на своєму боці.
