Průzkum přání komunity/Přiřazení priority

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 5% 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.

Jako výsledek Průzkumu je seznam seřazený podle počtu hlasů. Během let jsme zjistili, že není nejlepší nápad omezit se pouze na prvních 10.

Místo toho jsme vyvinuli systém prioritizace návrhů. Přiřazujeme je systematicky a transparentně. Tato prioritizace nám umožní se věnovat dokončení co možná nejvíce návrhům.

Popularita návrhu je důležitý faktor, ale ne jedeiný.
Nejlepší je pracovat na návrzích ve strategickém pořadí a dokončit jich co nejvíce.
V7vojáři a návrháři mohou pracovat každý na svém aniž by se navzájem blokovali. Například návrháři se mohou věnovat vizuální podobě, a vývojáři čistě technickým návrhům.
Je lepší komunikovat transparentně než skrývat detaily. Viditelnost zvyšuje důvěru.

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.

We also consult with other teams at the Foundation, and investigate if they were already working on projects related to proposals.

Technical Complexity

Criteria

Naši inženýři odhadují, kolik úsilí by museli vynaložit na splnění přání. Upřednostňují méně složité (lépe proveditelné) projekty. Kdykoli není něco jasné, snaží se spíše nadhodnocovat než podhodnocovat.

Technická závislost - zjišťujeme, zda práce vyžaduje součinnost s jinými týmy nadace Wikimedia. Může se stát, že část práce musí být v plánu jiných týmů nebo že potřebujeme vstupy nebo zpětnou vazbu jiných týmů, než budeme moci přání dokončit. Příkladem jsou změny schématu, bezpečnostní revize, přidání nového rozšíření a aktualizace knihoven třetích stran.
Technický výzkum - ptáme se sami sebe, zda víme, jak přistupovat k určitému problému. Někdy potřebujeme zhodnotit a zvážit své možnosti, než začneme přemýšlet o řešení. Někdy si potřebujeme potvrdit, že to, co je třeba udělat, lze udělat nebo že je to v rámci toho, co platforma, na které pracujeme, zvládne.
Technické úsilí - ptáme se, jak dobře známe základní kód a jak velký nebo složitý může být úkol. Vysoké skóre náročnosti může také znamenat, že kód, s nímž budeme pracovat, je starý, křehký nebo má určitý stupeň technického dluhu, s nímž se budeme muset vypořádat, než začneme pracovat na našem skutečném úkolu.

Scale

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

1 - Lowest Complexity	Technical solution is very simple - the problem exists in a contained part of the user experience as well the codebase Solution might already exist, developed by a community member in the form of a pre-existing gadget, extension, or code in a public repository Members of the engineering Community Tech team are familiar with the code Light QA testing required, just 1 task worth of QA
2 - Low Medium Complexity	Technical solution is discrete- the problem exists in a contained part of the user experience as well the codebase Solution might already exist, developed by a community member in the form of a pre-existing gadget, extension, or code in a public repository Members of the engineering Community Tech team are familiar with the code Almost no maintenance required Minimal code refactoring is required Possible third party code dependencies Light QA testing required, less than 5 tasks worth of QA
3 - Medium Complexity	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 Partial or no solution exists Members of the Community Tech team have limited knowledge of or are unfamiliar with the code A bit of maintenance required Code refactoring might be required Potentially adding third party dependencies QA testing required prior to release, 5+ tasks worth of QA
4 - Medium Large Complexity	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 Solution hasn’t been implemented Members of the Community Tech team have limited knowledge of or are unfamiliar with the code Maintenance is required Some database schema changes may be required Code refactoring is required Changes to authentication/security components are required i.e. authentication, feature flags, access controls Potentially adding third party dependencies QA testing required prior to release, 5+ tasks worth of QA
5 - Large Complexity	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 A system or new tool may need to be developed Members of the Community Tech team are unfamiliar with the code Maintenance required Some database schema changes may be required Code refactoring is required Changes to authentication/security components are required i.e. authentication, feature flags, access controls Potentially adding third party dependencies QA testing required prior to release, 5+ tasks worth of QA
6 - Extra large Complexity	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 A system or new tool may need to be developed Members of the Community Tech team are unfamiliar with the codebase the wish pertains to Maintenance required Substantial code refactoring is required Difficult database schema changes may be required Substantial code refactoring is required Changes to authentication/security components are required i.e. authentication, feature flags, access controls Add third party code dependencies QA testing required prior to release, 10+ tasks worth of QA

Product and Design Complexity

Criteria

Podobně jako u výše uvedených hodnocení náš designér odhaduje, jaké úsilí je třeba vynaložit na dokončení projektu. Upřednostňují méně složité (lépe proveditelné) projekty. Kdykoli není něco jasné, snaží se spíše nadhodnocovat než podhodnocovat.

Výzkumné úsilí návrhu - snažíme se zjistit, jaká úroveň výzkumu je pro každý návrh potřebná. V tomto případě výzkum zahrnuje pochopení problému, a to buď na samém začátku prostřednictvím počátečních zjišťovacích prací (rozsah a podrobnosti projektu, průzkumy nebo rozhovory se členy komunity), nebo později v průběhu procesu prostřednictvím komunitních diskusí a testování použitelnosti. (např. jak uživatelé přispívají s touto novou funkcí a bez ní).
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.

Scale

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

1 - Lowest Complexity	Design Solution is embedded into the wish proposal itself-- it’s a technical fix and no UI changes are necessary No data collection necessary No discovery user survey collection No unmoderated user research No design
2 - Low Medium Complexity	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 Requires little to no unmoderated research Prior to tackling the wish, we already collected the data necessary to make informed product & design decisions
3 - Medium Complexity	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 Limited to designing for one type of user need
4 - Medium Large Complexity	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 Limited to designing for two types of user needs Touches more than one page in the experience but it is generally limited to a subset of the experience and straightforward
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