1. Introdução

Uma das experiências mais frustrantes que alguém pode ter como um usuário de um software é submeter um relatório sobre um problema que está enfrentando apenas para vê-lo ser sumariamente fechado com uma informação curta e pouco útil do tipo “isto não é um bug” ou ainda “este relatório de problema não procede”. Da mesma forma, uma das experiências mais frustrantes para um desenvolvedor de software é ser inundado com relatórios de problemas que na verdade não são realmente relatórios de problemas, mas sim solicitações de suporte, ou então que contenham pouca ou nenhuma informação sobre como o problema ocorre e sobre como proceder para reproduzi-lo.

Este documento tem por objetivo descrever como escrever bons relatórios de problema. Mas o que vem a ser um bom relatório de problema? Bem, indo direto ao ponto, um bom relatório de problema é aquele que se pode analisar e tratar rapidamente, para a satisfação mútua do usuário e do desenvolvedor.

Embora o foco primário deste artigo seja a elaboração de relatórios de problemas no FreeBSD, a maior parte das recomendações deve aplicar-se muito bem a outros projetos de software.

Observe que este artigo esta organizado de forma temática, e não de forma cronológica, desta forma você deve ler o documento inteiro antes de enviar um relatório de problema, ao invés de tratá-lo como um tutorial passo-a-passo.