Список побажань спільноти/Як внести побажання
Як написати гарне побажання
Ми хотіли б почути пропозиції щодо покращення проєктів Вікімедіа. Як Commtech, ми хочемо мати можливість розділити нашу роботу на менші частини, побажання повинні бути більшими за помилку, але займати менше року з точки зору інженерної роботи. Оскільки ми усвідомлюємо той факт, що припинення роботи інструменту може бути значним обсягом роботи, ми також приймаємо побажання, які пропонують видалити технологію, щоб зрозуміти інтерес. У будь-якому випадку, ми спробуємо колективно відсортувати роботу як Фонд і передати її відповідним внутрішнім зацікавленим сторонам, щоб підвищити обізнаність про потреби спільноти.
Prioritisation
Щоб мати змогу пріоритезувати вхідні бажання, ми звіряємо їх зі стратегічними цілями, на які спрямовані Річний план. Читання Річного плану перед тим, як висловити бажання, не є обов'язковою умовою, але ви можете це зробити, якщо хочете краще зрозуміти процес сортування. Крім того, ми також розглядаємо три основні фактори, щоб визначити, чи варто визначати масштаб та намагатися реалізувати бажання:
- Побажання, що мають чіткий та вимірюваний вплив на спільноту, такі як збільшення залученості (редагування, пошук, виявлення тощо), на відміну від побажань, де вплив роботи може бути важче виміряти (якщо взагалі є);
- Бажання, які взагалі не мають обхідного шляху для полегшення основної проблеми порівняно з тими, які мають обхідний шлях (інтуїтивний чи ні);
- Побажання, що мають широкий спектр застосування для критичного набору функцій або користувачів на відміну від побажань, які можуть бути актуальними лише для обмеженого кола користувачів (наприклад, нова функція, досвідчені користувачі).
More specific criteria:
| Priority | Impact | Severity | Community scope |
|---|---|---|---|
| Highest | Measurable impact to OKR metrics | No workaround and may further deteriorate | Widespread and reproducible for a core feature or set of users |
| High | Non-core metrics are trackable or likely correlated | Complex workaround degrades UX or creates technical debt | Reproducible for sure, but not widespread enough for most users |
| Medium | Unclear whether wish would have any measurable impact | Intuitive workaround exists for users to circumvent issue | Not consistently reproducible - might be a niche use case |
| Low | No measurable impact | No severity - just a way to better polish a feature | Scope is unknown or may be unique use case |
Це не вичерпний список, а лише для того, щоб ви були прозорі щодо того, що проходить через наш процес сортування. Незалежно від того, скільки голосів отримує побажання, ми сортуємо все, і ви можете допомогти нам, надавши більше контексту за допомогою наведених вище порад.
Wishes out of scope
Малоймовірно, що ми працюватимемо над технічними редагуваннями або роботою, яка потребує змін у політиці. У багатьох випадках створення абсолютно нового застосунку чи алгоритму може бути поза межами наших можливостей. WMF не створюватиме гаджети чи ботів, але ви можете додавати побажання щодо гаджетів/ботів для розгляду членами спільноти.
Focus on a problem, not a specific solution
Хоча офіційної рубрики для написання «доброго побажання» немає, ми заохочуємо авторів побажань чітко сформулювати «один проблемний випадок», з яким вони стикаються, не надаючи чіткого рішення, щоб волонтери та персонал мали простір для спільного вирішення проблеми. Потенційні рішення можна обговорити та спільно створити на сторінці обговорення, і в результаті цих розмов опис побажання можна оновити та розширити на основі спільних знань.
Побажання, що демонструють емпатію та показують проблеми та цілі користувача, уникають пасток надмірної вузькості чи специфічністі, а також випадків, коли інші користувачі можуть прискіпуватися до рішення.
У наведеному нижче «прикладі» як побажання, орієнтоване на проблему, так і побажання, орієнтоване на рішення, натякають на поліпшення досвіду «нових редакторів».
Приклад, орієнтований на проблему, залишає рішення відкритим і запрошує до співпраці, тоді як приклад, орієнтований на рішення, може отримати негативні відгуки від учасників, які опираються перейменуванню користувацького «пісочниці». Щодо побажань щодо проблем, які можна вирішити безліччю технічних способів, рекомендується не робити рішення занадто вузькими та уникати опису лише одного з кількох взаємовиключних можливих рішень.
Таким чином, побажання, орієнтоване на проблему, може мати більші шанси бути віднесеним до пріоритетної області.
| Побажання, сфокусоване на проблемі (бажане) | Побажання, сфокусоване на рішенні (небажане) | |
|---|---|---|
| Назва | Спростити для новачків створення їхньої першої статті | Перейменувати чернетку на «Чернетку статті» |
| Опис | Особливо для нових редакторів може бути складно знайти пісочницю користувача. Після того, як вони знаходять свою пісочницю, нові редактори бачать низку застережень, які ускладнюють набуття впевненості у написанні якісної статті. Це впливає на здатність новачків долучитися до Вікіпедії та відчувати себе впевнено як автори. Це частково зроблено навмисно — ми повинні враховувати робочі процеси патрульних — але такий досвід заважає нам залучати нових редакторів. | Посилання «Чернетка» незрозуміле для нових користувачів. Перейменуймо його на «Чернетку статті», щоб люди частіше починали створювати саме чорновий варіант статті. |
| Тип | Системна зміна | Запит на функцію |
| Проєкт | Вікіпедія | Вікіпедія |
| Користувачі, яких це стосується | Нові редактори та, в подальшому, патрульні, які перевіряють нові редагування | Редактори |
| Завдання PhabР | необов'язково | T123456 |
Також слід уникати побажань, що поєднують «кілька проблем». Можливо, виборці погоджуються з деякими проблемами та ідеями, але не погоджуються з іншими. Так само Фонду та зацікавленим сторонам може бути важко впоратися з багатогранними побажаннями, якщо вони стосуються кількох програмних компонентів.