Jump to content

Розвиток спроможностей спільноти/Врядування спільноти

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Capacity Development/Community governance and the translation is 99% complete.
Outdated translations are marked like this.


Зміст цієї сторінки в кількох словах: Обговорення викликів і можливих підходів для розвитку спроможності спільноти щодо врядування спільноти, ролей, політик і правил.


Опис

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

  1. Створення та перегляд політики
  2. Ролі в управлінні

Через взаємопов'язаність ролей в управлінні та правил, їх проблеми та цілі описані разом. Тим не менш, проблеми та цілі специфічні для тільки політик чи тільки ролей описані окремо.

Опис спроможності щодо "Політик"

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

Розгляд проблем та цілей цієї спроможності сфокусований на "процесах" та "можливостях" створення та переоцінки політик в інтересах спільноти редакторів та читачів. Він не буде фокусуватись на якійсь політиці чи наборі політик.

Фонд Вікімедія вважає, що не зважаючи на спосіб створення політик, їх якість та перевірність вони є "єдиною мірою здоров'я спільноти".

Опис спроможності щодо "Ролей у врядуванні"

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

Виклики

Ролі у врядуванні

  • Позбавлення прав (адміністраторів, бюрократів, чек'юзерів, тощо): деякі ситуації можуть призвести до необхідності позбавлення прав за неактивність, зловживання, згідно рішень Арбітражного комітету. Але причини та частота позбавлень прав відрізняються в різних спільнотах. Для деяких спільнот позбавлення прав може бути дуже складним з різних причини, наприклад через відсутність недвозначних та ефективних правил, велику терміновість процесів. Відсутність чітких правил чи процесів позбавлення прав впливає на можливість спільноти боротися з неприйнятною поведінкою адміністраторів, коли такі прояви виникають, наприклад з погрозами, проявами дратівливості внаслідок вигорання або цькуванням новачків, територіальністю або авторитарністю ("синдром засновника").
  • Обмежене використання чи неефективність Арбітражних комітетів: Багато мовних проектів не мають Арбітражного комітету. В той час як Арбітражні комітети можуть не бути потрібними чи ефективними для всіх мовних проектів, деякі спільноти, які вже мають цей комітет чи колись спробували мати, вважають їх неефективними чи недостатньо активними.

Політики, яких бракує

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

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

Запровадження правил, яких бракує, робить процес редагування простішим, а стосунки в спільноті менш конфліктними.

Тим не менш, важливою умовою запровадження політик, яких бракує є визначення прогалин у правилах.

Неадекватні політики

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

Інколи складно визначити, чи дана політика непридатна, чи вона справді шкідлива і чи може вона стати джерелом розчарування для всього проекту. Навіть якщо якась політика всіма визнана непридатною, процес її зміни буває досить складним.

Існує чотири різні типи непридатних правил:

Мертві правила

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

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

Мертві правила можуть створювати деякі специфічні проблеми:

  • Якщо існуючого правила не дотримуються, суттєво страждає політика врядування спільноти. І потреба більш відповідного правила прихована існуванням мертвого правила.
  • Існування недіючих політик, таких які постійно порушуються добропорядними користувачами, кидають тінь на інші правила. Це може відкрити шлях до вибіркового дотримання правил у спільноті загалом.

Спірні політики

Спірною є політика, які не була широко підтримана значною більшістю спільноти активних редакторів. Ця політика може викликати активні суперечки, а може викликати пасивну незгоду, проте вона збурює спільноту постійними спалахами чвар з приводу тлумачення чи змісту політики. Основними проблемами, до яких призводять спірні політики, є:

  • Часті конфлікти через порушення політики (або у відповідь на вимоги її дотримання), які відволікають редакторів від змістовного внеску чи якихось корисніших обговорень.
  • Складнощі в залученні нових редакторів, у тому числі через суперечливі поради та відгуки про політику чи вимоги щодо її дотримання.

Неоднозначні або складні політики

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

  • Складнощі в залученні нових редакторів. Неоднозначних політик важко дотримуватись, не маючи виняткових "вікіінстинктів", ускладнені політики важко засвоїти всі й одразу, їх майже неможливо "перетравити", тим більше одним масивом.
  • "Політ-прокурорство": цим терміном можна означити певні типи зловживань окремими користувачами, які присвячують свій час вниканню у тонкощі політик, до тої міри, до якої інші користувачі б це не робили, і які потім намагаються демотивувати "неюристів" та допекти їм. Деякими прикладами є: дотримуватися букви правил, порушуючи їх мету, без потреби використовувати правову термінологію чи занадто формалізовані процедури для дискусій, виправдовувати неприйнятну поведінку за допомогою "лазівок" чи формальностей.[1]
  • Потрібно доволі часу, щоб правильно розтлумачити двозначну політику чи вирішити, як точно її застосувати через надмірну складність. Іноді це призводить до затяжних суперечок, які вичерпуються скоріше через втому, аніж через компроміс.

Інші типи непридатних політик

Політика може бути широко підтримуваною, добре зрозумілою і дотримуваною, але все одно викликати розчарування, конфлікти чи марну втрату часу на проекті, тому що вона може бути неадекватною до поточного стану проекту.

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

Можливі цілі створення та перевірки правил

Аналіз та оцінка

  • Опитування щодо правил: Почнемо з того, що спільнота повинна визначити одне або декілька правил, які потребують уваги. Іноді є правила які очевидно потребують уваги і широко відомі серед активних редакторів, але якщо це не так, першим етапом має бути опит щодо існуючих правил (а також правил, яких бракує, дивлячись на правила в інших проектах), щоб оцінити, чи всі правила є зрозумілими, недвузначними, дотримуваними і підходящими для проекту.
  • Порівняння правил: Після того, як були визначені непридатні правила або правила, яких бракує, порівняння правил з відповідними правилами інших проектів може допомогти знайти розв'язання проблеми. Це порівняння правил має порівнювати не тільки зміст правил, але в ідеалі також визначити недоліки та переваги цього правила на думку деяких активних редакторів проекту, з правилом якого проводиться порівняння.
  • Статистика правила: Для деяких правил є наявною статистика та дані. Наприклад, статистика про рішення про видалення (наприклад Скільки було голосів? Яке співвідношення між "за" і "проти"? Який був середній розмір сторінки обговорення видалення?) яка відбулось після обговорення може допомогти зробити правильний висновок щодо критеріїв значимості.
  • Групова перевірка окремих випадків: Зібрати велику групу досвідчених редакторів щоб перевірити нещодавні випадки і порівняти бажаний/ідеальний результат або рішення з результатом, який дало правило. Наприклад, перевірити декілька нещодавно поставлених на видалення статтей щоб визначити як критерії значимості відповідають очікуванням активних редакторів; перевірити декілька нещодавних кандидатів на статус Вибранної статті і визначити чи відповідає результат очікуванням спільноти.
  • Оффлайновий мозковий штурм: Рішення щодо правил мають завжди прийматися на вікі. Але іноді, особливо якщо попередні спроби перевірити правила чи досягнути консенсусу не вдалися, можна зібрати якомога більше активних редакторів оффлайн, щоб зробити мозковий штурм та спробувати дійти консенсусу, а потім перенести обговорення назад у вікі для підтвердження всією спільнотою.
  • Зробіть експеримент: Поекспериментуйте з можливими результатами пропонованих правил, включаючи план переходу, методи досягнення результату, процедуру відкату, тощо.

Досягнення змін правил: потенціальний процес

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

  1. Сформулюйте потребу в змінах: Щоб створювати чи перевірияти правила необхідно мати чіткий та короткий опис поточних білих плям в правилах або чому діюче правило не підходить поточним вимогам проекту. Повинно бути зрозуміло як пропоновані зміни (принаймі потенційно) задоволнять потреби спільноти.
  2. Зберіть інформацію, альтернативні чи специфічні пропозиції: Завжди легше опиратись на конкретні дані, альтернативні чи деталізовані пропозиції, ніж на відкриті питання "якою має бути наша політика щодо оплачуваних редагувань?".
  1. Полегшіть обговорення в спільноті: Нехай спільнота обговорить потреби та пропозиції. Дайте редакторам досить часу для того щоб висловити свою думку (не менше тижня). Залучіть до обговорення: людей, які не були залучені до попередніх аналізів та обговорень, редакторів з різними інтересами, ролями та стажем. В ідеалі напишіть короткі змісти, щоб кожен міг залишатися в курсі всіх, навіть дуже довгих, тем та обговорень
  1. Дійдіть згоди щодо того робити щось чи ні: Дискусія має закінчитись згодою на зміни або запровадження правил або ж згодою нічого не робити та зберегти "статус-кво". Останнє іноді є правильним рішенням, якщо не було знайдено гарних альтернатив або якщо з'явилась переконлива критика пропозиції, яку раніше вважали гарною.
  2. Задокументуйте рішення: Незалежно від того, яке було прийнято рішення, дуже важливо завершити процес документуванням рішення. Якщо вирішено запровадити чи змінити правило, то важливо письмово точно вказати що саме зміниться, а що залишиться таким як було, вказати необхідний на це час та дати набуття чинності нових правил чи змін та необхідні перехідні та проміжні кроки.

Начерк можливого проекту покращення спроможностей

Проблема
складнощі у перевірці застарілих критеріїв значимості
Ціль
Досягнути широкопітримуваного рішення спільноти щодо того чи змінювати критерії значимості. Якщо прийнято рішення змінювати їх, то спроектувати та запровадити нові правила.
Основні кроки
  1. Сформулювати недоліки діючого правила
  2. Залучитись підтримкою ініціювання обговорення щодо зміни
  3. Ініціювати широке обговорення в спільноті про можливі зміни правила, а також:
    1. Надати порівняльний аналіз критеріїв значимості з інших проектів
    2. Зібрати активних редакторів оффлайн та спробувати спроектувати пропозицію для подальшого обговорення в спільноті
  4. Завершити обговорення в спільноті прийняттям рішення та його документуванням.
Відведений час
6 місяців
Засоби та ресурси
Підтримка Фонду Вікімедія в створенні порівняльного аналізу правил; Надання Фондом Вікімедія коштів для оффлайн зустрічі
Оцінки
  1. Провести опитування спільноти до і після проекту, щоб оцінити корисність критеріїв значимості, рівень та частоту виникнення конфліктів пов'язаних з критеріями значимості
  2. виміряти частоту запитів на видалення пов'язаних з критеріями значення до і після їх зміни (якщо зміни відбулись).

Ресурси

Внизу надано список ресурсів, який не є вичерпним. Будь ласка, додайте будь-які ресурси які ви вважаєте можуть бути корисними!

Додайте свої ідеї

Випадки застосування

  • ще нема

Примітки

Interested communities

The Wikimedia Foundation is interested in assisting interested communities in considering and achieving policy change, for instance through research, external conversation facilitation, and funding for face-to-face meetings.


Sign up below if you are interested in implementing this in your local community: