Lista de desejos comunitários/Como escrever um bom desejo
Como escrever um bom desejo
Gostaríamos de ouvir sugestões para melhorias nos projetos da Wikimedia. Como Commtech, queremos poder dividir nosso trabalho em partes menores; os pedidos devem ser maiores do que um bug, mas levar menos de um ano em termos de trabalho de engenharia. Como sabemos que desativar uma ferramenta pode ser um trabalho considerável, também levamos em consideração pedidos que sugerem a remoção de uma tecnologia para entender o interesse. De qualquer forma, tentaremos priorizar o trabalho coletivamente como Fundação e encaminhá-lo às partes interessadas internas relevantes para aumentar a conscientização sobre as necessidades da comunidade.
Priorização
Para priorizar os desejos recebidos, cruzamos as informações com as metas estratégicas definidas no Plano Anual. A leitura do Plano Anual não é obrigatória antes de fazer um desejo, mas você pode fazê-lo se quiser entender melhor o processo de triagem. Além disso, também consideramos três fatores principais para determinar se devemos ou não avaliar e tentar implementar um pedido:
- Desejos que têm um impacto claro e mensurável na comunidade, como aumentar o engajamento (edição, busca, descoberta, etc.), em oposição a desejos em que pode ser mais difícil medir o impacto do trabalho (ou mesmo não medi-lo);
- Desejos que não têm nenhuma solução alternativa para aliviar o problema subjacente versus aqueles que têm uma solução alternativa (intuitiva ou não);
- Desejos que têm um amplo alcance para um conjunto crítico de funcionalidades ou usuários versus desejos que podem ser relevantes apenas para um conjunto limitado de usuários (por exemplo, funcionalidades em desenvolvimento, usuários avançados).
Critérios mais específicos:
| Prioridade | Impacto | Gravidade | Escopo da comunidade |
|---|---|---|---|
| Mais alto | Impacto mensurável nas métricas de OKR | Não há solução alternativa e pode piorar ainda mais a situação | Amplamente disseminado e reproduzível para uma funcionalidade principal ou conjunto de usuários |
| Alto | As métricas não essenciais são rastreáveis ou provavelmente correlacionadas | Soluções alternativas complexas degradam a experiência do usuário ou criam dívida técnica | Reproduzível com certeza, mas não suficientemente difundido para a maioria dos usuários |
| Médio | Não está claro se o desejo teria algum impacto mensurável | Existe uma solução alternativa intuitiva para os usuários contornarem o problema | Não é reproduzível de forma consistente - pode ser um caso de uso específico |
| Baixo | Nenhum impacto mensurável | Sem gravidade - apenas uma forma de aprimorar uma funcionalidade | O escopo é desconhecido ou pode ser um caso de uso único |
Esta não é uma lista exaustiva, mas serve apenas para dar transparência sobre o que passa pelo nosso processo de triagem. Independentemente da quantidade de votos que um pedido recebe, nós triamos todos, e você pode nos ajudar fornecendo mais contexto com as dicas acima.
Desejos fora do escopo
É improvável que trabalhemos em edições técnicas ou em projetos que exijam mudanças nas políticas. Em muitos casos, criar um aplicativo ou algoritmo totalmente novo pode estar fora do escopo. A WMF não criará gadgets ou bots, mas você pode adicionar sugestões de gadgets/bots para serem consideradas pelos membros da comunidade.
Concentre-se no problema, não em uma solução específica
Embora não haja uma regra oficial para escrever um "bom desejo", incentivamos os proponentes a articular um problema que enfrentam sem fornecer uma solução explícita, para que voluntários e funcionários tenham espaço para resolver problemas juntos. Possíveis soluções podem ser discutidas e cocriadas na página de discussão e, como resultado dessas conversas, a descrição do pedido pode ser atualizada e ampliada, com base no aprendizado compartilhado.
Desejos que demonstram empatia e mostram os desafios e objetivos do usuário evitam as armadilhas de serem muito específicos ou de nicho, e onde outros usuários podem criticar a solução.
No exemplo abaixo, tanto o exemplo de desejo baseado em problemas quanto o de desejo baseado em soluções sugerem melhorias na experiência do "novo editor".
O exemplo orientado a problemas deixa a solução em aberto e convida à colaboração, enquanto o exemplo orientado a soluções pode receber feedback negativo de colaboradores que resistem a renomear uma página de testes de usuário. Para solicitações relacionadas a problemas que podem ser abordados de diversas maneiras técnicas, recomenda-se não restringir demais a(s) solução(ões) e evitar descrever apenas uma entre várias soluções possíveis que sejam mutuamente exclusivas.
Dessa forma, o desejo motivado pelo problema pode ter uma chance maior de ser atribuído a uma área de foco.
| Desejo guiado por problemas (encorajado) | Desejo guiado por solução (desencorajado) | |
|---|---|---|
| Título | Facilite a criação do primeiro artigo para iniciantes | Renomear página de testes (sandbox) para "Editor de rascunho" (Draft editor) |
| Descrição | Especialmente para novos editores, pode ser difícil encontrar uma página de testes para o usuário. Assim que a encontram, os novos editores se deparam com uma série de avisos de isenção de responsabilidade que dificultam a aquisição de confiança na escrita de um artigo de boa qualidade. Isso afeta a capacidade do novato de se integrar à Wikipédia e se sentir confiante como colaborador. Isso ocorre em parte por design – precisamos estar atentos aos fluxos de trabalho do patrulhador – mas a experiência prejudica nossa capacidade de integrar novos editores. | O termo "Página de testes" é confuso para novos usuários. Vamos renomeá-lo para "Editor de rascunhos" para que as pessoas tenham mais probabilidade de rascunhar um artigo. |
| Tipo | Mudança de sistema | Solicitação de recurso |
| Projeto | Wikipédia | Wikipédia |
| Usuários afetados | Novos editores e, a jusante, patrulheiros que revisam novas edições | Editores |
| Tarefas Phab | opcional | T123456 |
Desejos que combinam múltiplos problemas também devem ser evitados. Pode ser que os eleitores concordem com alguns problemas e ideias, mas discordem de outros. Da mesma forma, a Fundação e as partes interessadas podem achar difícil lidar com desejos multifacetados se eles envolverem vários componentes de software.