Community Wishlist Survey/Prioritization/pt-br

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

Este artigo foi escrito para os voluntários, entusiastas da lista de desejos da comunidade e colaboradores avançados. Nós, Comunidade Técnica, queremos descrever como planejamos nosso trabalho após o término da fase de votação das propostas. Esperamos explicar nossos processos de desenvolvimento de software. Agradecemos comentários sobre a clareza deste documento.

Como resultado de cada edição da lista de desejos da comunidade, há uma nova lista de propostas ordenadas pelo número de votos. Ao longo dos anos, aprendemos que comprometer-se a trabalhar no top 10 não é a melhor ideia.

Em vez disso, desenvolvemos um método para priorizar as propostas. Nós as avaliamos de forma sistemática e transparente. A priorização nos ajuda a decidir como trabalhar para que possamos concluir o maior número possível de propostas. Existem algumas suposições:

  • A popularidade de uma proposta deve ser um fator muito importante em nossa decisão de seleção, mas não o único.
  • É melhor trabalhar nas propostas em uma ordem estratégica e concluir o maior número possível.
  • Engenheiros e projetistas devem poder trabalhar uns com os outros sem bloquear um ao outro. Por exemplo, enquanto o designer verifica a proposta e gera componentes visuais, os engenheiros se concentram em propostas puramente técnicas.
  • É melhor se comunicar de forma transparente com as comunidades, em vez de ocultar os detalhes. A visibilidade gera confiança e diálogo.

Resumo dos critérios

Ao priorizar, analisamos as 30 propostas mais populares. Não analisamos nenhuma proposta abaixo disso, porque não podemos conceder mais de 30 desejos por ano. Classificamos as propostas com base na popularidade, complexidade técnica e de design, bem como no impacto na comunidade. Veja alguns critérios:

photo of prioritization score
Pontuação de priorização das propostas

Uma vez que cada proposta é pontuada, nós as classificamos e trabalhamos de acordo com essa classificação. Só assim podemos:

  • Trabalhar o maior número possível de desejos com os recursos que temos.
  • Optar por causar o maior impacto, levando em consideração a manutenção e a complexidade.

Também consultamos outras equipes da Fundação e investigamos se já estavam trabalhando em projetos relacionados a proposta.

Complexidade técnica

Critério

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 uma delas é classificada em uma escala de 1 a 6:

1 - Complexidade mais baixa
  • A solução técnica é muito simples - o problema existe em uma parte contida da experiência do usuário, bem como no código base
  • A solução pode já existir, desenvolvida por um membro da comunidade na forma de um gadget, extensão ou código pré-existente em um repositório público
  • Os membros da equipe Comunidade Técnica estão familiarizados com o código
  • Teste leve de controle de qualidade necessário, apenas uma tarefa
2 - Complexidade média-baixa
  • A solução técnica é discreta - o problema existe em uma parte contida da experiência do usuário, bem como no código base
  • A solução pode já existir, desenvolvida por um membro da comunidade na forma de um gadget, extensão ou código pré-existente em um repositório público
  • Os membros da equipe Comunidade Técnica estão familiarizados com o código
  • Quase nenhuma manutenção necessária
  • Refatoração mínima de código é necessária
  • Possíveis dependências de código de terceiros
  • Teste leve de controle de qualidade necessário, menos de 5 tarefas
3 - Complexidade média
  • A solução técnica é aberta - o problema existe em várias partes da experiência do usuário, bem como em uma ou várias partes do código base ou repositórios
  • Solução parcial ou inexistente
  • Os membros da equipe Comunidade Técnica têm conhecimento limitado ou não estão familiarizados com o código
  • Necessita de um pouco de manutenção
  • Refatoração de código pode ser necessária
  • Potencialmente dependências de terceiros
  • Teste de controle de qualidade necessário antes do lançamento, mais de 5 tarefas
4 - Complexidade média-alta
  • A solução técnica é aberta - o problema existe em várias partes da experiência do usuário, bem como em uma ou várias partes do código base ou repositórios
  • A solução não foi implementada
  • Os membros da equipe Comunidade Técnica têm conhecimento limitado ou não estão familiarizados com o código
  • A manutenção é necessária
  • Algumas alterações no banco de dados podem ser necessárias
  • Refatoração do código é necessária
  • São necessárias alterações nos componentes de segurança, ou seja, autenticação, controles de acesso, etc.
  • Potencialmente dependências de terceiros
  • Teste de controle de qualidade necessário antes do lançamento, mais de 5 tarefas
5 - Complexidade alta
  • A solução técnica tem incógnitas - o problema existe em várias partes da experiência do usuário, bem como em uma ou várias partes do código base ou repositórios
  • Pode ser necessário desenvolver um sistema ou uma nova ferramenta
  • Os membros da equipe Comunidade Técnica não estão familiarizados com o código
  • Manutenção requerida
  • Algumas alterações no banco de dados podem ser necessárias
  • Refatoração do código é necessária
  • São necessárias alterações nos componentes de segurança, ou seja, autenticação, controles de acesso, etc.
  • Potencialmente dependências de terceiros
  • Teste de controle de qualidade necessário antes do lançamento, mais de 5 tarefas
6 - Complexidade muito alta
  • A solução técnica tem muitas incógnitas - o problema existe em várias partes da experiência do usuário, bem como em uma ou várias partes do código base ou repositórios
  • É necessário desenvolver um sistema ou uma nova ferramenta
  • Os membros da equipe Comunidade Técnica não estão familiarizados com o código base à qual o desejo pertence
  • Manutenção requerida
  • Refatoração substancial de código é necessária
  • Mudanças difíceis no banco de dados podem ser necessárias
  • Refatoração substancial de código é necessária
  • São necessárias alterações nos componentes de segurança, ou seja, autenticação, controles de acesso, etc.
  • Dependências de código de terceiros
  • Teste de controle de qualidade necessário antes do lançamento, mais de 10 tarefas

Complexidade do produto/design

Critérios

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 uma delas é classificada em uma escala de 1 a 6:

1 - Complexidade mais baixa
  • O design é incorporada à própria proposta de desejo - é uma correção técnica e nenhuma alteração na interface do usuário é necessária
  • Nenhuma coleta de dados necessária
  • No discovery user survey collection
  • Sem pesquisa não moderada
  • Sem design
2 - Complexidade média-baixa
  • As alterações são isoladas em apenas um número limitado de locais (ou seja, as alterações afetam apenas uma página ou um projeto da Wikimedia)
  • Requer pouca ou nenhuma coleta inicial de dados para entender o comportamento e o ponto problemático
  • Requer pouca ou nenhuma pesquisa não moderada
  • Antes de abordar o desejo, já coletamos os dados necessários para tomar decisões sobre o produto/design
3 - Complexidade média
  • Antes de abordar o desejo, já coletamos a maioria dos dados para tomar decisões sobre o produto/design, mas podemos exigir o rastreamento de novos dados antes de começar a entender o problema
  • 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 - Complexidade média-alta
  • 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
  • Requer uma pesquisa no início do desejo
  • 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 - Complexidade alta
  • Requires qualitative discovery and quantitative data collection
  • Requer pesquisa não moderada e é difícil obter participantes devido à complexidade do desejo
  • Pode exigir a criação de novas informações técnicas na interface do usuário
  • Requires touching multiple pages in the flow
  • Requer uma pesquisa no início do desejo
  • Requires touching multiple pages in the flow and or has cross-project implications
  • Impacts across multiple user states, for example
    • Editores
    • Leitores
    • Proofreaders etc.
6 - Complexidade muito alta
  • 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
    • Leitores
    • Colaboradores
    • Novatos

Impacto na comunidade

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.

Resultados de 2022 classificados por priorização

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

Terminologia

Pesquisa não moderada

Usando uma ferramenta como UserTesting.com para executar “simulações” de nossas alterações de design propostas e ver se estamos projetando a solução de desejo correta - é chamada de "não moderada" porque permitimos que os usuários cliquem e vejam que nossos designs fazem sentido sem ter que explicar a eles

Coleta de dados quantitativos

O processo de coleta de dados para entender como os usuários estão interagindo com a IU atual para entender os pontos problemáticos do desejo - sejam dados sobre cliques, visitas, downloads, etc. Os dados geralmente são limitados quando abordamos um desejo pela primeira vez devido à falta de rastreamento antes do desejo ou dados inexistentes devido a motivos de privacidade

Coleta de dados qualitativos

Compreender o problema do desejo conversando diretamente com os usuários, seja por meio de entrevistas ou por meio de uma pesquisa no início do desejo, para entender os pontos problemáticos e esclarecer como abordar uma solução

“Sourcing” users

O processo de encontrar usuários que tenham o conhecimento necessário para participar de nossos testes e nos fornecer as informações de que precisamos para entender se nossas decisões de design e produto estão no caminho certo. Alguns desejos são para usuários avançados, que são difíceis de encontrar e não estão disponíveis em ferramentas como UserTesting.com

Refatoração de código

O processo de tornar o código existente mais fácil de manter para que outras pessoas possam contribuir com o código, bem como remover problemas técnicos e bugs.

Mudanças no banco de dados

A alteração de estruturas de todo ou parte de um banco de dados relacional. Quando uma alteração em um banco de dados existente é necessária, ele deve ser projetada e aprovada por uma equipe externa. Isso geralmente leva mais tempo e adiciona complexidade estrutural ao projeto.

Código de terceiros

Código escrito fora da equipe Comunidade Técnica, exemplos incluem APIs.