Community Wishlist Survey/Prioritization/ru

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

This article is written for the volunteers, enthusiasts of Community Wishlist Survey and advanced contributors. We, Community Tech, want to describe how we plan our work on proposals after the voting phase ends. We hope to explain our processes of software development. We welcome feedback about the clarity of this document.

В результате каждого Опроса пожеланий сообщества получается новый список предложений, отсортированный по числу голосов. За прошедшие годы мы поняли, что вкладываться в работу именно над первыми десятью из них — не лучшая идея.

Вместо этого вы разработали метод расстановки приоритетов над предложениями. Мы оцениваем их систематическим и прозрачным образом. Расстановка приоритетов помогает нам решить, как проводить работу так, что мы могли реализовать как можно больше предложений. Есть несколько соображений:

Популярность предложения должна быть очень важным фактором при принятии решения о выборе, но не единственным.
Лучше всего работать над предложениями стратегически и реализовать как можно больше из них.
Инженеры и дизайнеры должны иметь возможность работать вместе, не мешая друг другу. Например, пока дизайнер изучает предложение и готовит для предложений визуальную составляющую, инженеры фокусируются на чисто технических предложениях.
It is best to communicate transparently with the communities rather than hiding the details. Visibility builds trust and dialogue.

Summary of criteria

When prioritizing, we review the 30 most popular proposals. We do not review any proposals below that, because we are not be able to grant more than 30 wishes per year. We score the proposals based on popularity, technical and product & design complexity, as well as community impact. The following summarizes the criteria:

Once every proposal is scored, we rank them and work according to this ranking. Only then we can:

Work on the most possible number of wishes with the resources we have.
Choose to make the biggest impact while taking maintenance and complexity into account.

Мы также советуемся с другими командами Фонда и разбираемся, работают ли они уже над проектами, связанными с поступившими предложениями.

Техническая сложность

Критерии

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.

Шкала

Each of these is ranked on a 1-6 scale:

1 — Наименьшая сложность	Техническое решение является очень простым — Участник сталкивается с проблемой в ограниченном числе случаев, и она относится к конкретному участку кода Решение может уже существовать — в виде гаджета, разработанного членом сообщества, расширения или кода в публичном репозитории Код знаком членам инженерной группы Технической команды сообщества Требуется незначительное тестирование качества с 1 задачей
2 — Сложность ниже среднего	Техническое решение имеет чёткий характер — Участник сталкивается с проблемой в ограниченном числе случаев, и она относится к конкретному участку кода Solution might already exist, developed by a community member in the form of a pre-existing gadget, extension, or code in a public repository Код знаком членам инженерной группы Технической команды сообщества Поддержка почти не требуется Нужна минимальная переработка кода Код может стать зависим от сторонних ресурсов Требуется незначительное тестирование качества с менее чем 5 задачами
3 — Средняя сложность	Technical solution is open-ended-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories Решение отсутствует, или есть частичное Члены Технической команды сообщества незнакомы или малознакомы с кодом Требуется некоторый уровень поддержки Может быть нужна переработка кода Вероятно, код становится зависим от сторонних ресурсов Перед выпуском требуется тестирование качества с 5 и более задачами
4 — Сложность выше среднего	Technical solution is open-ended-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories Решение не внедрено Члены Технической команды сообщества незнакомы или малознакомы с кодом Требуется поддержка Требуются некоторые изменения схемы баз данных Требуется переработка кода Changes to authentication/security components are required i.e. authentication, feature flags, access controls Вероятно, код становится зависим от сторонних ресурсов Перед выпуском требуется тестирование качества с 5 и более задачами
5 — Высокая сложность	The technical solution has unknowns-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories Может быть нужна разработка системы или нового инструмента Члены Технической команды сообщества незнакомы с кодом Требуется поддержка Могут быть нужны некоторые изменения схемы баз данных Требуется переработка кода Changes to authentication/security components are required i.e. authentication, feature flags, access controls Вероятно, код становится зависим от сторонних ресурсов Перед выпуском требуется тестирование качества с 5 и более задачами
6 — Крайне высокая сложность	The technical solution has many unknowns-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories Может быть нужна разработка системы или нового инструмента Члены Технической команды сообщества незнакомы с кодом, связанным с пожеланием Требуется поддержка Требуется значительная переработка кода Могут быть нужны сложные изменения схемы баз данных Требуется значительная переработка кода Changes to authentication/security components are required i.e. authentication, feature flags, access controls Код становится зависим от сторонних ресурсов Перед выпуском требуется тестирование качества с 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.

Шкала

Each of these is ranked on a 1-6 scale:

1 — Наименьшая сложность	Дизайнерское решение включено в предложение — Это техническое исправление, не требующее изменений интерфейса Не требует сбора данных No discovery user survey collection Не требует немодерируемого (без подсказок) пользовательского тестирования Не требует разработки дизайна
2 — Сложность ниже среднего	Changes are isolated to just a single page inside of the experience with limited number of states (i.e. changes only impact one page / one wikimedia project) Requires little to no initial data collection to understand behavior and pain point via survey or quantitative data Не требует или почти не требует немодерируемого (без подсказок) тестирования Prior to tackling the wish, we already collected the data necessary to make informed product & design decisions
3 — Средняя сложность	Prior to tackling the wish, we already collect most of the data to make informed product & design decisions but may require tracking new data prior to starting to understand the problem Requires unmoderated user research but it is not difficult to “source” users for those flows May touch more than one page in the experience but it is generally limited to a subset of the experience and straightforward Необходима разработка дизайна для 1 типа потребностей участников
4 — Сложность выше среднего	Prior to tackling the wish, we already collect some of the data to make informed product & design decisions but may require tracking new data prior to starting to understand the problem Requires unmoderated user research but it is not difficult to “source” users for those flows May touch more than one page in the experience but it is generally limited to a subset of the experience and straightforward Requires a survey at the beginning of wish Необходима разработка дизайна для не более чем 2 типов потребностей участников Touches more than one page in the experience but it is generally limited to a subset of the experience and straightforward
5 — Высокая сложность	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 Может потребовать разработки дизайна для включения в интерфейс новой технической информации 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 Редакторы Читатели Корректоры и т. д.
6 — Крайне высокая сложность	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: Редакторы Читатели Contributors Новички

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