Опитування побажань спільноти/Ранжування

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 70% complete.

Ця стаття написана для волонетрів, ентузіастів Опитування побажань спільноти та заангажованих дописувачів. Ми, Community Tech, хочемо описати, як ми плануємо опрацьовувати пропозиції після завершення голосування. Ми сподіваємось пояснити наш процес розробки програмного забезпечення. Просимо про відгуки стосовно чіткості документа.

Внаслідок кожного редагування Опитування побажань спільноти виникає новий порядок побажань, посортованих за голосами. Протягом років ми переконались, що простий відбір до роботи 10-ти найпопулярніших не є найкращим способом вибору.

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

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

Загальні критерії

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

Після бальної оцінки пропозицій ми розташовуємо їх у порядку спадання. Лише потім ми можемо:

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

Ми також консультуємось з іншими командами Фонду та довідуємось, чи вони не працюють над подібними проєктами.

Технічна складність

Критерії

Our engineers estimate how much effort they would need to put into granting a wish. They prioritize less complex (more workable) projects. Whenever something is not clear, they try to overestimate rather than underestimate.

Technical dependency – we check if the work requires interactions with other Wikimedia Foundation teams. It could be that part of the work needs to be on other teams' roadmap or that we need other teams' input or feedback before we can complete the wish. Examples of these are schema changes, security reviews, adding a new extension, and upgrading third-party libraries.
Technical research – we ask ourselves if we know how to approach a particular problem. Sometimes we need to evaluate and consider our options before we can start thinking about a solution. Sometimes we need to confirm that what needs to be done can be done or is within what the platform we are working on can handle.
Technical effort – we ask ourselves how familiar we are with the underlying code and how big or complex the task can be. A high-effort score could also mean that the code we'll be working with is old, brittle, or has some degree of technical debt that will have to be dealt with before we can start working on our actual task.

Рівень

Кожен з критеріїв оцінюється балами від 1 до 6:

1 - Найнижчої складності	Технічне вирішення дуже просте — проблема зустрічається в практиці учасників та у відомому кодуванні Рішення може вже існувати в попередніх розробках членів спільноти у формі існуючого ґаджету, розширення чи коду доступного публічно Членам інженерного сектора команди Community Tech відомий потрібний код Вимагається нескладне тестування якості, лише одна задача для тестування якості
2 - Низької складності	Технічне вирішення відносно просте — проблема зустрічається в практиці учасників та у відомому кодуванні Рішення може вже існувати в попередніх розробках членів спільноти у формі існуючого ґаджету, розширення чи коду доступного публічно Членам інженерного сектора команди Community Tech відомий потрібний код Підтримки майже не вимагається Потрібна минимальная переробка коду Кодування можна отрмиати від партнерів Вимагається нескладне тестування якості, менше п'яти задач для тестування якості
3 — Середня складність	Технічне рішення є відкритим – проблема існує в кількох частинах взаємодії з користувачем, а також в одній або кількох частинах кодової бази чи сховищ Рішення часткове або не існує Члени Технічної команди спільноти не знайомі або малознайомі з кодом Потрібно трохи обслуговування Може знадобитися рефакторинг коду Потенційне додавання залежності від третіх сторін Необхідне тестування якості перед випуском, 5+ завдань, які варті перевірки якості
4 - Середня велика складність	Технічне рішення є відкритим – проблема існує в кількох частинах взаємодії з користувачем, а також в одній або кількох частинах кодової бази чи сховищ Рішення не реалізовано Члени команди Community Tech мають обмежені знання або не знайомі з кодом Потрібне технічне обслуговування Можливо, знадобляться деякі зміни схеми бази даних Потрібен рефакторинг коду Потрібні зміни до компонентів автентифікації/безпеки, наприклад автентифікації, позначок функцій, контролю доступу Потенційне додавання залежності від третіх сторін Необхідне тестування якості перед випуском, 5+ завдань, які варті перевірки якості
5 — Висока складність	Технічне рішення має невідомі дані – проблема існує в кількох частинах взаємодії з користувачем, а також в одній або кількох частинах кодової бази чи сховищ Можливо, потрібно буде розробити систему або новий інструмент Члени команди Community Tech не знайомі з кодом Потрібне технічне обслуговування Можливо, знадобляться деякі зміни схеми бази даних Потрібен рефакторинг коду Потрібні зміни до компонентів автентифікації/безпеки, наприклад автентифікації, позначок функцій, контролю доступу Потенційне додавання залежності від третіх сторін Необхідне тестування якості перед випуском, 5+ завдань, які варті перевірки якості
6 - Надвелика складність	Технічне рішення має багато невідомих – проблема існує в кількох частинах взаємодії з користувачем, а також в одній або кількох частинах кодової бази чи сховищ Можливо, потрібно буде розробити систему або новий інструмент Члени команди Community Tech не знайомі з кодовою базою, якої стосується це бажання Потрібне технічне обслуговування Потрібен істотний рефакторинг коду Може знадобитися складна зміна схеми бази даних Потрібен істотний рефакторинг коду Потрібні зміни до компонентів автентифікації/безпеки, наприклад автентифікації, позначок функцій, контролю доступу Add third party code dependencies Необхідне тестування якості перед випуском, 10+ завдань для перевірки якості

Продукт і складність дизайну

Критерії

Similarly to the assessments above, our designer estimates what effort should be made to complete a project. They prioritize less complex (more workable) projects. Whenever something is not clear, they tries to overestimate rather than underestimate.

Design research effort – we seek to understand the level of research needed for each proposal. In this case, the research involves understanding the problem, either at the very beginning through initial discovery work (the scope and details of the project, surveys or interviews with community members), or later in the process through community discussions and usability testing (e.g. how do users contribute with and without this new feature).
Visual design effort – a significant number of proposals require changes in the user interface of Wikimedia projects. Therefore, we check to estimate the change of the user interface, how many elements need to be designed and their complexity. For instance, using existing components from our design system or creating new ones, keeping in mind how many states or warnings need to be conceived to help guide users, including newcomers.
Workflow complexity – we ask ourselves how does this particular problem interfere with the current workflows or steps in the user experience of editors. For example, a high score here would mean that there are a lot of different scenarios or places in the user interface where contributors might interact with a new feature. It can also mean that we might have to design for different user groups, advanced and newcomers alike.

Рівень

Кожен з них оцінюється за шкалою від 1 до 6:

1 - Найнижчої складності	Дизайнерське рішення вбудоване в саму пропозицію - це технічне виправлення, і не потрібно змінювати інтерфейс користувача Збір даних не потрібен Немає колекції опитувань користувачів Немає немодерованих досліджень користувачів Без дизайну
2 - Низької складності	Зміни поширюються лише на одну сторінку всередині досвіду з обмеженою кількістю станів (тобто зміни впливають лише на одну сторінку / один проект Wikimedia) Для розуміння поведінки та больової точки за допомогою опитування чи кількісних даних не потрібно майже жодного початкового збору даних Не потребує немодерованих досліджень Перш ніж втілити це бажання, ми вже зібрали дані, необхідні для прийняття обґрунтованих рішень щодо продукту та дизайну
3 — Середня складність	Перш ніж задовольнити це бажання, ми вже зібрали «більшість» даних, щоб приймати обґрунтовані рішення про продукт і дизайн, але може знадобитися відстеження нових даних, перш ніж почати розуміти проблему Потрібне немодероване дослідження користувачів, але знайти користувачів для цих потоків неважко Може стосуватися кількох сторінок досвіду, але зазвичай обмежується підмножиною досвіду та є простим Обмежується розробкою для одного типу потреб користувача
4 - Середня велика складність	Перш ніж вирішити це бажання, ми вже збираємо «деякі» дані, щоб приймати обґрунтовані рішення про продукт і дизайн, але може знадобитися відстеження нових даних, перш ніж почати розуміти проблему Потрібне немодероване дослідження користувачів, але знайти користувачів для цих потоків неважко Може стосуватися кількох сторінок досвіду, але зазвичай обмежується підмножиною досвіду та є простим Потрібне опитування на початку бажання Обмежується розробкою для двох типів потреб користувачів Торкається більше ніж однієї сторінки досвіду, але зазвичай обмежується підмножиною досвіду та є простим
5 - Large Complexity	Requires qualitative discovery and quantitative data collection Requires unmoderated user research and the users for the research are hard to source given the complexity of wish Can require designing new technical information into the UI Requires touching multiple pages in the flow Requires a survey at the beginning of wish Requires touching multiple pages in the flow and or has cross-project implications Impacts across multiple user states, for example Editors Readers Proofreaders etc.
6 - Extra Large Complexity	Requires investigation by the process of qualitative discovery and quantitative data collection Potentially controversial implications that must be mitigated by working with communities Requires unmoderated user research and the users for the research are hard to source given the complexity of designs Requires designing for a “learning curve” or introducing new technical information into the UI Requires touching multiple pages in the flow and or has cross-project implications Impacts across multiple user states and across needs: Editors Readers Contributors Newcomers

Community Impact

In contrast to the two perspectives described above, this part is about equity. Practically, it's about ensuring that the majorities aren't the only ones whose needs we work on.

Depending on this score, proposals with similar numbers of votes and similar degrees of complexity are more or less likely to be prioritized. If a given criterion is met, the proposal gets +1. The more intersections, the higher the score. This assessment was added by our Community Relations Specialist.

Not only for Wikipedia – proposals related to various projects and project-neutral proposals, are ranked higher than projects dedicated only to Wikipedia. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article