Escrevendo relatos de bugs de maneira eficiente
Atualização em 22/06/2006: você precisa logar no sistema para abrir ou modificar um ticket. Essa decisão foi tomada a fim de evitar spammers. Criamos um usuário genérico para isso. Utilize-o! Usuário: debian-br-cdd e Senha: debian-br-cdd (continue lendo o resto da página...)
Ao preencher um ticket de relato de bug deve-se sempre procurar ser o mais descritivo possível e fornecer a maior quantidade possível de detalhes sobre o problema. Tenha em mente que um relato de bug mal escrito pode fazer com que os desenvolvedores não entendam o que você escreveu e simplesmente acabem fechando o bug como inválido.
Lembre-se de fornecer um endereço de e-mail válido, pois alguns bugs para serem resolvidos exigem que os desenvolvedores entrem em contato com a pessoa que o reportou. Vale salientar que tickets com mais de 30 dias sem uma resposta serão fechados.
Caso o bug que você esteja relatando possa ser reproduzível, por favor, liste os passos necessários para reproduzi-lo.
E agora algumas regrinhas de como preencher corretamente um ticket de relato de bug:
- No primeiro campo informe seu e-mail ou, caso seja um desenvolvedor já cadastrado, seu login. Relatos anônimos são aceitos porém é preferivel que eles sejam identificados pois permitem o contato da equipe de desenvolvimento com quem relatou o bug.
- Logo depois coloque um resumo sobre o que se trata o bug.
- Em seguida forneça uma descrição detalhada. Procure fornecer o máximo de detalhes possíveis, tendo em mente o que foi citado antes.
- Nas propriedades do ticket (Ticket Properties) preencha da seguinte forma:
- Component: escolha a qual seção do BR-CDD este problema está relacionado. Caso não saiba especifique o valor 'outro'.
- Version: informe em qual versão do BR-CDD este problema ocorreu. Este campo é muito importante pois é através dele que sabemos em qual versão ele ocorre direcionando sua solução.
- Severity: diga a severidade deste bug. Caso não saiba responder informe 'normal'.
- Keywords: forneça algumas palavras-chaves para serem utilizadas pelo mecanismo de busca.
- Priority: a prioridade com que este bug deve ser resolvido. Deixe em normal, pois a equipe de desenvolvimento atribuirá a prioridade correta.
- Milestone: deixe em branco. A equipe de desenvolvimento preencherá adequadamente.
- Assing to: deixe em branco também. Posteriormente a equipe de desenvolvimento vai atribuir este bug para algum integrante.
- Cc: forneça seu e-mail.
