Lista de Desejos da Comunidade/Como escrever um bom desejo
Como escrever um bom desejo
Gostaríamos de ouvir sugestões de melhorias para os projetos Wikimedia. Como Commtech, queremos ser capazes de dividir o nosso trabalho em pequenas partes; os desejos devem ser maiores do que um bug, mas exigir menos de um ano de trabalho de engenharia. Como estamos cientes de que descontinuar uma ferramenta pode ser um trabalho considerável, também aceitamos desejos que sugiram remover tecnologia para compreender o interesse. Em qualquer caso, tentaremos triagem do trabalho coletivamente como Fundação e encaminhá-lo aos intervenientes internos relevantes para aumentar a consciencialização sobre as necessidades da comunidade.
Priorização
Para poder priorizar os desejos recebidos, nós verificamo-los cruzando com os objetivos estratégicos definidos através do Plano Anual. Não é obrigatório ler o Plano Anual antes de fazer um desejo, mas pode fazê-lo se quiser compreender melhor o processo de triagem. Além disso, também analisamos três fatores principais para determinar se devemos definir o âmbito e tentar implementar um desejo:
- Desejos que tenham um impacto claro e mensurável na comunidade, como aumentar o envolvimento (edição, pesquisa, descoberta, etc.), em contraste com desejos em que pode ser mais difícil medir o impacto do trabalho (se é que é possível);
- 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 alcance amplo para um conjunto crítico de funcionalidades ou utilizadores versus desejos que podem ser apenas relevantes para um conjunto limitado de utilizadores (por exemplo, funcionalidade nascente, utilizadores avançados).
Critérios mais específicos:
| Prioridade | Impacto | Gravidade | Escopo da comunidade |
|---|---|---|---|
| Mais alto | Impacto mensurável nos métricas OKR | Não há solução alternativa e pode deteriorar-se ainda mais | Amplo e reproduzível para uma funcionalidade principal ou conjunto de utilizadores |
| Alto | Métricas não essenciais são rastreáveis ou provavelmente correlacionadas | Solução complexa degrada a experiência do utilizador ou cria dívida técnica | Reproduzível com certeza, mas não suficientemente difundido para a maioria dos utilizadores |
| Médio | Não está claro se o desejo teria algum impacto mensurável | Existe uma solução alternativa intuitiva para os utilizadores contornarem o problema | Não é consistentemente reproduzível - poderá ser um caso de uso específico |
| Baixo | Sem impacto mensurável | Sem gravidade - apenas uma forma de aprimorar melhor uma funcionalidade | O escopo é desconhecido ou pode ser um caso de uso único |
Esta não é uma lista exaustiva, mas apenas para lhe dar transparência sobre o que passa pelo nosso processo de triagem. Independentemente de quantos votos um desejo receba, fazemos a triagem de tudo e você pode nos ajudar fornecendo mais contexto com as dicas acima.
Desejos fora do escopo
É pouco provável que trabalhemos em edições técnicas ou trabalhos que exijam alterações de políticas. Em muitos casos, criar uma aplicação ou algoritmo completamente novo pode estar fora do escopo. A WMF não irá criar gadgets ou bots, mas podes adicionar pedidos de gadgets/bots para consideração pelos membros da comunidade.
Concentre-se num problema, não numa solução específica
Embora não exista uma rubrica oficial para escrever um "bom desejo", encorajamos os proponentes de desejos a articular um único problema que enfrentam sem fornecer uma solução explícita, de forma a que os voluntários e a equipa tenham espaço para resolver o problema juntos. Potenciais soluções podem ser discutidas e cocriadas na página de discussão e, como resultado destas conversas, a descrição do desejo pode ser atualizada e ampliada, com base nos aprendizados partilhados.
Desejos que demonstram empatia e mostram os desafios e objetivos de um utilizador evitam as armadilhas de serem demasiado específicos ou restritos, e onde outros utilizadores podem criticar a solução.
No exemplo abaixo, tanto os exemplos de desejos conduzidos pelo problema como os conduzidos pela solução sugerem melhorar as experiências do "novo editor".
O exemplo orientado por problemas deixa a solução em aberto e convida à colaboração, enquanto o exemplo orientado por soluções pode receber feedback negativo de contribuintes que resistem a renomear uma página de testes de utilizador. Para desejos sobre problemas que podem ser abordados de múltiplas formas técnicas, recomenda-se não tornar a(s) solução(ões) demasiado estreita(s) e evitar descrever apenas uma de várias soluções possíveis mutuamente exclusivas.
Assim, o desejo orientado para o problema pode ter uma maior probabilidade de ser atribuído a uma área de enfoque.
| Desejo orientado por problema (encorajado) | Desejo orientado por solução (desaconselhado) | |
|---|---|---|
| Título | Facilitar aos novatos a criação do seu primeiro artigo | Renomeie a área 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 de utilizador. Uma vez que encontram a sua página de testes, os novos editores veem uma série de avisos que tornam difícil ganhar confiança na escrita de um artigo de boa qualidade. Isto impacta a capacidade de um novato de integrar-se na Wikipédia e de se sentir confiante como colaborador. Isto é em parte intencional – precisamos de ter em conta os fluxos de trabalho dos revisores – mas a experiência dificulta a nossa capacidade de integrar novos editores. | O termo "Sandbox" é confuso para utilizadores novos. Vamos renomeá-lo para "Editor de rascunhos" para que as pessoas tenham mais probabilidade de rascunhar um artigo. |
| Tipo | Alteração de sistema | Pedido de funcionalidade |
| Projeto | Wikipédia | Wikipédia |
| Utilizador afetados | Novos editores e, a jusante, patrulhadores que analisam novas edições | Editores |
| Tarefas do Phab | opcional | T123456 |
Desejos que combinam vários problemas também devem ser evitados. Pode acontecer 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 os desejos multifacetados difíceis de abordar se envolverem múltiplos componentes de software.