Jump to content

Encuesta de Lista de Deseos de la Comunidad/Prioritization

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 57% complete.

Este articuló está escribiendo para los voluntarios, entusiastas de la Encuesta de Lista de Deseos de la Comunidad y colaboradores avanzados. Nosotros, Tecnología Comunitaria, queremos describir cómo planeamos nuestro trabajo en las propuestas después de que termine la fase de votación. Esperamos poder explicar nuestros procesos de desarrollo de software. Damos la bienvenida a los comentarios sobre la claridad de este documento.

Como resultado de cada edición de la Encuesta de Deseos de la Comunidad, hay una nueva lista de propuestas ordenada por número de votos. Con los años, aprendimos que comprometernos a trabajar en las 10 más votadas no es la mejor idea.

En vez de eso, desarrollamos un método para priorizar las propuestas. Las evaluamos sistemática y transparentemente. La priorización nos ayuda a decidir cómo trabajar, para que podamos completar tantas propuestas como sea posible. Existen algunos supuestos:

  • La popularidad de una propuesta debería ser un factor muy importante en nuestra decisión, pero no el único.
  • Es mejor trabajar las propuestas en un orden estratégico y completar cuantas sea posible.
  • Los ingenieros y diseñadores deberían poder trabajar juntos sin bloquearse entre sí. Por ejemplo, mientras el diseñador investiga la propuesta y genera componentes para las propuestas, los ingenieros se enfocan en propuestas que son puramente técnicas.
  • Lo mejor es comunicarse de manera transparente con las comunidades en lugar de ocultar los detalles.

Resumen de los criterios

A la hora priorizar, repasamos las 30 propuestas mas popular. No revisamos ninguna propuesta por debajo de eso, porque no podemos conceder más de 30 deseos por año. Calificamos las propuestos en función de la popularidad, la complejidad téchnica y del producto y el diseño, así como el impacto en la comunidad. A continuación se resumen los criterios.

photo of prioritization score
Puntaje de priorización para Propuestas del Técnica Comunitaria

Después de puntuar todas las propuestas, las ordenamos y trabajamos en función de esa clasificación. Sólo entonces podremos:

  • Trabajar en el máximo posible de deseos con los recursos de que disponemos.
  • Elegir las que tengan el mayor impacto, teniendo en cuenta el mantenimiento y la complejidad.

También consultamos con otros equipos de la Fundación, e investigamos si ya estaban trabajando en proyectos relacionados con las propuestas.

Complejidad técnica

Criterios

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.

Escala

Cada uno de estos se clasifica en una escala de 1 a 6:

1 - Complejidad mas baja
  • La solución técnica es muy sencilla - el problema existe en una parte contenida de la experiencia del usuario, así como la base de código (codebase).
  • Es posible que la solución ya exista, desarrollada por un miembro de la comunidad en forma de gadget preexistente, extensión o código en un repositorio público.
  • Los miembros del equipo de ingeniería de Community Tech (Tecnología Comunitaria) están familiarizados con el código.
  • Se requieren pruebas de control de calidad ligeras, solo 1 tarea de control de calidad
2 - Complejidad media baja
  • La solución técnica es discreta - el problema existe en una parte contenida de la experiencia del usuario, así como la base de código (codebase).
  • Es posible que la solución ya exista, desarrollada por un miembro de la comunidad en forma de gadget preexistente, extensión o código en un repositorio público.
  • Members of the engineering Community Tech team are familiar with the code
  • Casi no requiere mantenimiento
  • Se requiere refactorización de código mínima
  • Posibles dependencias de código de terceros
  • Se requieren pruebas de control de calidad ligeras, menos de 5 tareas de control de calidad
3 - Complejidad Media
  • 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
  • Solución parcial o no existe
  • Miembros de Tecnología Comunitaria tienen un conocimiento limitado o no están familiarizados con el código.
  • Un poco de mantenimiento requerido
  • Es posible que se requiera una refactorización de código
  • Potentially adding third party dependencies
  • QA testing required prior to release, 5+ tasks worth of QA
4 - Complejidad Media Grande
  • 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
  • La solución no ha sido implementada
  • Members of the Community Tech team have limited knowledge of or are unfamiliar with the code
  • Se requiere mantenimiento
  • Some database schema changes may be required
  • Se requiere refactorización de código
  • Se requieren cambios en los componentes de autenticación-seguridad, es decir, autenticación, indicadores de funciones, controles de acceso
  • Potencialmente agregando dependencias de terceros
  • Pruebas de control de calidad requeridas antes del lanzamiento, más de 5 tareas por valor de control de calidad
5 - Complejidad Grande
  • 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
  • Es posible que sea necesario desarrollar un sistema o una nueva herramienta
  • Members of the Community Tech team are unfamiliar with the code
  • Requiere mantenimiento
  • Some database schema changes may be required
  • Se requiere refactorización de código
  • Changes to authentication/security components are required i.e. authentication, feature flags, access controls
  • Potencialmente agregando dependencias de terceros
  • Pruebas de control de calidad requeridas antes del lanzamiento, más de 5 tareas por valor de control de calidad
6 - Complejidad extra grande
  • La solución técnica tiene muchas incógnitas--el problema existe en varios partes de la experiencia del usuario, así como una o varias partes de de la base de código o repositorios
  • Es posible que sea necesario desarrollar un sistema o una nueva herramienta
  • Los miembros del equipo Técnica Comunitaria no están familiarizados con el código base al que pertenece el deseo
  • Requiere mantenimiento
  • Se requiere usa refactorización sustancial del código
  • 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

Complejidad del producto y del diseño

Criterios

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.

Escala

Cada uno de estos se clasifica en una escala de 1 a 6:

1 - Complejidad mas baja
  • Design Solution is embedded into the wish proposal itself-- it’s a technical fix and no UI changes are necessary
  • No es necesaria la recopilación de datos
  • No discovery user survey collection
  • No unmoderated user research
  • No diseño
2 - Complejidad media baja
  • 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 - Complejidad Media
  • 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 - Complejidad Media Grande
  • 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 - Complejidad Grande
  • 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
    • Editores
    • Lectores
    • Correctores etc.
6 - Complejidad Extra Grande
  • 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:
    • Editores
    • Lectores
    • Colaboradores
    • Recién llegados

Impacto de la comunidad

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]] is an example of a prioritized proposal.
  • Sister projects and smaller wikis – we additionally prioritize proposals about the undersupported projects (like Wikisource or Wiktionary). We counted Wikimedia Commons as one of these. [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]] is an example of a prioritized proposal.
  • Critical supporting groups – we prioritize proposals dedicated to stewards, CheckUsers, admins, and similar groups serving and technically supporting the broader community. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] is an example of a prioritized proposal.
  • Reading experience – we prioritize proposals improving the experience of the largest group of users – the readers. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] is an example of a prioritized proposal.
  • Non-textual content and structured data – we prioritize proposals related to multimedia, graphs, etc. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] is an example of a prioritized proposal.
  • Urgency – we prioritize perennial bugs, recurring proposals, and changes which would make contributing significantly smoother. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] is an example of a prioritized proposal.
  • Barrier for entry – we prioritize proposals about communication and those which would help to make the first contributions. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] is an example of a prioritized proposal.

== Resueltos de 2022 clasificados por Puntaje de Priorización

These scores may change when we start working on the proposals. As we explained above, we have tried to overestimate rather than underestimate. Check out the proposals, in order of prioritization:

Wish Popularity Rank Votes Engineering Score Product and Design Score Community Impact Score Prioritization Score
[[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]] 29 69 1.0 0.3 2 2.66
[[Community Wishlist Survey 2022/Miscellaneous/Get WhatLinksHere's lists in alphabetical order|Get WhatLinksHere's lists in alphabetical order]] 22 74 1.3 0.3 2 2.63
[[Community Wishlist Survey 2022/Search/Enable negation for tag filters|Enable negation for tag filters]] 26 71 2.0 0.3 2 2.47
[[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]] 11 93 2.3 0.7 2 2.47
[[Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering|Improve SVG rendering]] 5 108 4.0 0.8 3 2.44
[[Community Wishlist Survey 2022/Anti-harassment/Notifications for user page edits|Notifications for user page edits]] 2 123 1.3 1.7 1 2.38
[[Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere|Check if a page exists without populating WhatLinksHere]] 14 89 2.7 0.7 2 2.38
[[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]] 4 109 4.3 2.7 4 2.21
[[Community Wishlist Survey 2022/Reading/IPA audio renderer|IPA audio renderer]] 9 97 3.0 2.7 3 2.15
[[Community Wishlist Survey 2022/Reading/floating table headers|floating table headers]] 24 73 1.0 2.7 2 2.14
[[Community Wishlist Survey 2022/Admins and patrollers/Mass-delete to offer drop-down of standard reasons, or templated reasons.|Mass-delete to offer drop-down of standard reasons, or templated reasons.]] 25 72 1.0 2.7 2 2.14
[[Community Wishlist Survey 2022/Editing/Formatting columns in table|Formatting columns in table]] 19 77 4.0 0.3 2 2.11
[[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] 8 100 3.0 2.0 2 2.07
[[Community Wishlist Survey 2022/Translation/Add DeepL as a machine translation option in ContentTranslation|Add DeepL as a machine translation option in ContentTranslation]] 20 75 3.3 0.0 1 2.06
[[Community Wishlist Survey 2022/Search/Change default number of search results displayed|Change default number of search results displayed]] 12 92 2.0 1.7 1 2.05
[[Community Wishlist Survey 2022/Editing/Better diff handling of paragraph splits|Better diff handling of paragraph splits]] 1 157 3.3 2.3 1 2.04
[[Community Wishlist Survey 2022/Mobile and apps/Table sorting on mobile|Table sorting on mobile]] 17 83 2.3 1.7 1 1.92
[[Community Wishlist Survey 2022/Miscellaneous/Enhanced Move Logs|Enhanced Move Logs]] 10 96 2.7 2.3 1 1.79
[[Community Wishlist Survey 2022/Bots and gadgets/Gadget: Who is active|Gadget: Who is active]] 26 71 1.3 4.0 2 1.76
[[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]] 3 120 4.0 3.7 2 1.61
[[Community Wishlist Survey 2022/Admins and patrollers/Reminders or edit notifications after block expiration|Reminders or edit notifications after block expiration]] 20 75 3.3 3.2 2 1.57
[[Community Wishlist Survey 2022/Wikidata/Autosuggest linking Wikidata item after creating an article|Autosuggest linking Wikidata item after creating an article]] 12 92 3.3 3.8 2 1.53
[[Community Wishlist Survey 2022/Mobile and apps/Full page editing|Full page editing]] 30 67 2.0 3.7 1 1.42
[[Community Wishlist Survey 2022/Miscellaneous/Allow filtering of WhatLinksHere to remove links from templates|Allow filtering of WhatLinksHere to remove links from templates]] 6 106 5.0 3.3 2 1.40
[[Community Wishlist Survey 2022/Citations/Automatic duplicate citation finder|Automatic duplicate citation finder]] 6 106 3.0 4.2 1 1.36
[[Community Wishlist Survey 2022/Editing/VisualEditor should use human-like names for references|VisualEditor should use human-like names for references]] 22 74 3.3 4.0 1 1.12

In addition, if you are interested in viewing a more granular version of the sub-components that make the prioritization scores, we've made the individual sub-components public:

These are proposals which we found will be worked on by other teams at the WMF or third-party open source when we went through the process of estimating their complexities:

Tasks for other Product teams
Wish Popularity Rank
[[Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation|Deal with Google Chrome User-Agent deprecation]] 15
[[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]] 15
[[Community Wishlist Survey 2022/Mobile and apps/Categories in mobile app|Categories in mobile app]] 18
[[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|Mass uploader]] 28

Terminología útil

Investigaciones de usuarios no moderar

Using a tool like UserTesting.com to run “mocks” of our proposed design changes and see if we are designing the right wish solution-- it’s called “unmoderated” because we let users click around and see our designs makes sense without having to explain it to them

Quantitative data collection

The process of collecting data to understand how users are interacting with the current UI to understand the wish’s pain points -- be it data regarding clicks, visits, downloads, sessions etc. Data is often limited when we first tackle a wish due to lack of tracking it prior to wish, or nonexistent data due to privacy reasons

Qualitative data collection

Understanding the wish’s problem space by talking directly to users, be it interviews or via a survey at the beginning of the wish to understand the pain points and clarify how to tackle a solution

“Sourcing” users

The process of finding users who have the knowledge required to participate in our user tests and give us the information we need to understand if our design and product decisions are headed in the right direction. Some wishes are for advanced users, which are hard to source and not available in tools like UserTesting.com

Refactorización de código

The process of making the existing code more maintainable so that other people may contribute to the code, as well as removing technical debt and bugs.

Database schema changes

The alteration to a collection of logical structures of all or part of a relational database. When a change to an existing database is needed, it must be designed and then approved by a team external to CommTech. This usually takes more time and adds structural complexity to the project.

Third party code

Code written outside of the Community Tech team, examples include APIs or libraries.