Controle de Qualidade/Relatório de erro
TDF LibreOffice Brasil Document Liberation Project Community Blogs Traduções Nextcloud Redmine Perguntas e respostas Doar
Que bom que você chegou aqui. Você está prestes a dar uma importante contribuição ao LibreOffice. Um bom relatório de bug é muito útil para nossos desenvolvedores. Abaixo, você encontrará algumas orientações para facilitar esse processo.
Nem todos os bugs vão para o Bugzilla
All dogs may go to heaven
, mas alguns relatórios de bugs devem ser arquivados fora do Bugzilla. Esses incluem:
| Tipos de bugs | Onde registrar o bug |
|---|---|
| Extensões do LibreOffice | Com o autor da extensão |
| Infraestrutura TDF/LibreOffice (sites, listas de discussão, etc.) | Redmine |
| Construindo o LibreOffice | Lista de email do desenvolvedor |
| Testes de unitários do LibreOffice | Lista de email do desenvolvedor |
| Words missing from dictionaries | To the dictionary maintainer or repository |
| Mistakes in translations | Reporting them in Bugzilla is allowed, but it is more efficient to add them as suggestions in Weblate (does not require registration) |
Antes de enviar um bug
Confirme se realmente é um bug. Na maioria das vezes, um bug é algo que faz o software se comportar de uma maneira que um usuário comum não gostaria que ele se comportasse. Isso inclui o software não fazer o que você quer, fazer o que você nunca pediu ou simplesmente travar sob uso normal. Nos bastidores, um bug pode ser algo que faz com que o software demore muito mais e use muito mais recursos do que deveria.
Algumas falhas podem realmente ser o resultado de um perfil de usuário corrompido. Problemas com OpenGL (nas versões mais recentes procure por Skia) e OpenCL geralmente são bugs válidos. Ajuda muito, se você verificar os efeitos das configurações de OpenGL e OpenCL antes de escrever seu relatório de bug.
Em um certo ponto, o que parecem bugs são na verdade mais como solicitações de recursos, onde sabemos como o software deve funcionar em um mundo ideal, mesmo que o recurso que queremos ainda não tenha sido construído. Felizmente, você não precisa se preocupar tanto em separar bugs de solicitações de recursos. Se for algo que interfira no uso normal e válido do aplicativo, relate-o como um bug.
No entanto, ajuda muito se você conhece o LibreOffice, para que tenha uma boa noção do que é "uso normal e válido". Você não quer gastar muito tempo relatando o que você acha que são bugs quando o problema é que você ainda não sabe como usar um determinado recurso. Considere ler a documentação do usuário e use bastante os aplicativos para se familiarizar com o que eles normalmente fazem.
Se você conhece o LibreOffice razoavelmente bem e se depara com algo que pode ser um bug, mas pode ser apenas algo que você não entende, você pode postar uma pergunta na Lista de discussão de usuários do LibreOffice ou no Ask LibreOffice.
Mas, digamos que o que você encontrou realmente parece um bug. Veja o que fazer a seguir:
- Tome notas para não esquecer algo que estava acontecendo na época em que o bug apareceu. O que você estava fazendo, o que você esperava que acontecesse e o que realmente aconteceu? Como você sabia que algo estava errado? Você pode reproduzir o mau comportamento?
- Se possível, verifique se há relatos de bugs existentes semelhantes (Mas, evite gastar muito com isso, é melhor arquivar um dupe do que desistir):
- Vá para Componentes, e selecione o componente apropriado (ou subcomponente).
- Se você selecionou um componente: Selecione o subcomponente apropriado ou a Ajuda Estendida se não vir o subcomponente nessa página.
- Se você selecionou Ajuda Estendida: Selecione o subcomponente apropriado ou o [1] na parte inferior da lista, se você não encontrou ou não conhece o subcomponente apropriado.
- Você verá uma lista de bugs com esse subcomponente. Na parte inferior da página, selecione Editar pesquisa. Lá, você pode modificar a pesquisa de acordo com suas necessidades.
- Se você encontrar um relatório de bug relacionado ao seu problema, você pode contribuir com ele. Se você não encontrar um relatório de bug relacionado ao seu problema, registre um novo relatório de bug.
- Se o bug ocorrer apenas no Ubuntu ou estiver relacionado a impressão, vá para Mais informações.
- Depois de tudo isso, se não houver um relatório de bug sobre esse problema, siga as instruções em Enviando um bug.
Enviando um bug
Envie um relatório de bug separado para cada bug encontrado, mesmo que os sintomas do ponto de vista de um usuário pareçam idênticos. Diferentes problemas com diferentes raízes que apareceram em diferentes versões da LibreOffice podem ter que ser corrigidos por pessoas diferentes, para versões diferentes e em momentos diferentes. É impossível rastrear isso em um único relatório de bug.
Go to Bugzilla.
Entrar
Se você for solicitado a entrar, faça login com sua conta do Bugzilla.
If you don't have a Bugzilla account, create one by clicking New Account.
Componente
Em Componente, escolha o componente.
Se você não tiver certeza de qual componente é o seu problema, escolha o componente LibreOffice. Alguém revisará o relatório de bug mais tarde e escolherá um componente mais preciso. (Para mais informações sobre triagem, que é revisar bugs para colocar os mais importantes no topo da lista, dê uma olhada em "Triagem de bug".)
Se for um problema urgente (Partes quebradas, regressão, etc.), e você for um usuário experiente que conhece a equipe de desenvolvimento, você pode atribuir o relatório de bug a um dos desenvolvedores listados na página Entre um especialista.
Detalhes
Se houver uma seção Subcomponente, selecione o subcomponente.
Se você não souber o subcomponente apropriado, vá para Componentes. Nessa página, clique no componente apropriado. Leia as descrições de todos os subcomponentes na página desse componente. Se você não vir um subcomponente adequado, clique em Extended Help e leia as descrições dos subcomponentes na página that.
Escolha a versão do aplicativo em que o bug apareceu. Para verificar qual versão do LibreOffice você está usando, selecione ▸
Em Sistema operacional ou SO, escolha o sistema operacional do computador que você estava usando quando encontrou o bug.
Se houver uma seção Hardware, preencha-a.
Se houver uma seção Severity e você estiver relatando uma solicitação de recurso, selecione enhancement. Caso contrário, ignore-o, a menos que você seja experiente. Se você quiser saber as definições dos itens na seção Severity, consulte este gráfico.
Você pode ignorar a seção última versão de trabalho conhecida.
Assunto
Verifique na tabela "Bugs possivelmente relacionados" na página de relatórios de bugs e adicionalmente na Tabela de duplicatas para ver se o problema realmente não foi relatado ainda.
Na seção Assunto (também conhecida como Resumo):
- Não inclua informações já conhecidas dos campos.
- Inclua os nomes dos subcomponentes de Componentes.
- Deixe os subcomponentes em maiúsculo.
- Se o subcomponente puder ser confundido com partes de uma palavra (por exemplo, UI é parte da palavra quit), coloque o subcomponente entre colchetes.
- Use no máximo dois subcomponentes.
- Use os subcomponentes exatamente como aparecem na lista, mas você pode integrá-los na frase do assunto como “WIKIHELP [UI] não disponível em todos os idiomas”.
- Resuma o problema com bastante precisão.
- mau exemplo: “O arquivo está quebrado”
- melhor exemplo: “Menu Arquivo > Salvar como não disponível (Em cinza)”
- Evite contrações de palavras como “doesn’t” ou “isn’t” para facilitar as consultas de strings no Resumo; Em vez disso, use a forma completa, como "does not" ou "is not".
- Se o problema escrito no relatório for que o LibreOffice trava ou para de responder ("trava"), adicione a palavra CRASH ao Resumo, para que esses bugs possam ser localizados e rastreados facilmente.
Descrição e anexos
Na seção Descrição longa ou Descrição, forneça uma descrição mais longa e factual do problema:
- Listar os passos para reproduzir o bug;
- Use uma lista numerada; e
- Indique o método exato para fazer algo acontecer. Por exemplo, em vez de escrever “Abrir documento”, escreva “No novo documento de planilha LibreOffice vazio, use o menu Arquivo > Abrir (caixa de diálogo do LibreOffice) > tipo de arquivo “Documentos de texto” > selecione documento de amostra anexado > clique duas vezes”.
Se você estiver usando um LibreOffice pré-construído no Linux, liste as versões exatas dos pacotes do LibreOffice em seu sistema de gerenciamento de pacotes. Se você estiver usando o Windows, liste o nome de arquivo exato do instalador e de onde ele foi baixado.
- A inclusão de informações sobre a localização instalada e usada (idioma da interface do usuário, idioma do documento) pode ser útil.
- Inclua se um LibreOffice de 32 bits é usado em um sistema de 64 bits (Linux).
- Inclua o arquivo fonte do pacote se não for a versão oficial do LibreOffice.
Escreva o comportamento esperado e o comportamento real.
Você pode incluir um anexo, como uma captura de tela ou um documento de amostra. A maneira típica de fazer uma captura de tela é pressionar o botão "Print Screen/PrtScn" no teclado. Dependendo do seu sistema operacional, talvez seja necessário abrir um aplicativo de edição de imagem (como o Paint no Windows) e fazer Editar - Colar nele.
- Se você criar capturas de tela, mude o idioma para inglês antes de fazer a captura de tela. Você pode fazer isso em ▸ ▸ ▸ .
- Você pode tornar as capturas de tela mais úteis adicionando comentários e marcando áreas relevantes com o LibreOffice Draw.
- Se você deseja anexar mais de uma captura de tela, você deve coletar todas elas em um documento (copiar/colar em um documento do LibreOffice Draw) e anexar como PDF. Por favor, adicione um pequeno comentário a cada captura de tela para dizer o que você deseja demonstrar com ela.
- Se você anexar um documento de amostra que exiba o bug que você está relatando, faça o documento com o mínimo de texto o possível. Por exemplo, para bugs do Writer, o documento deve idealmente ter apenas um único parágrafo. Para facilitar a localização do texto do seu documento no rastreamento de depuração, use algum texto muito facilmente reconhecível, como AAAAAAAAAAA ₂ ZZZZZZZZZZ para um bug que é acionado por esse caractere.
- É preferível fazer upload de anexos individualmente. No entanto, se você quiser anexar vários documento, crie um arquivo .zip contendo todos os documentos e anexe esse .zip.
- Se o seu anexo for muito grande para ser anexado no Bugzilla (maior que 1 MB), você pode usar a Página de upload experimental.
Status
A única vez que você deve alterar o status para NEW é, se alguém já confirmou o bug em outro lugar (Pergunte na lista de discussão ou em algum fórum). Nesses casos, forneça um link para a discussão com a confirmação.
Enviar
Clique em Submit e seu relatório será adicionado ao banco de dados do Bugzilla.
Se o Bugzilla parece assustador
Se o sistema de rastreamento de bugs do Bugzilla parecer assustador ou muito difícil de entender, você deve postar seu problema aqui:
- ask LibreOffice -- suporte de usuário para usuário
- users@global.libreoffice.org lista de suporte ao usuário
Mesmo se você postar seu problema nesses canais, seu objetivo deve ser obter um bom relatório de bug no bugzilla. Esses canais podem ajudá-lo com isso. Observe que relatar problemas nas mídias sociais (Facebook, Twitter etc.) não é produtivo, pois, raramente levará a um bom relatório de bug que termine no bugzilla. (Veja também: 99 maneiras de arruinar um projeto de código aberto, top 5)
Depois de enviar um bug
Se ninguém revisou seu relatório dentro de um tempo apropriado (24 horas para um bug crítico, 14 dias para uma solicitação de aprimoramento), considere pedir a outra pessoa para reproduzir seu relatório de bug no site users@global.libreoffice.org Lista de Discussão ou canal IRC #libreoffice IRC://.
Adicionando comentários aos bugs
- Evite postar comentários “eu também” que não contenham informações adicionais úteis.
A exceção a isso é quando você comenta um bug que não foi UNCONFIRMED até agora. Nesse caso, forneça as etapas de reprodução (ou confirme as fornecidas pelo relator original) e mova o problema para o status NOVO. Observe que, se não houver etapas de reprodução claras, o problema pode voltar rapidamente para o NEEDINFO, portanto, é essencial encontrar um cenário de reprodução bom e simples. - Evite adicionar comentários do tipo “temos 1.000 licenças aqui e apenas este bug nos impede de migrar”, pois não contém informações adicionais relevantes para o controle de qualidade ou para a prioridade do problema.
O LibreOffice é de código aberto e sua ajuda para corrigir problemas relevantes para sua situação específica é muito bem-vinda. Você pode:
- Empregue e/ou ensine seus próprios desenvolvedores a trabalhar no LibreOffice. Estamos muito felizes em orientá-los: veja as páginas de desenvolvedores.
- Financie indivíduos ou empresas para trabalhar em questões específicas - veja a lista de desenvolvedores certificados.
- Contate a Document Foundation para ajudá-lo se você tiver apenas uma pequena quantia de financiamento e quiser colaborar, coordenar ou reunir seus recursos com outros na mesma situação para financiar correções ou melhorias específicas.
Bons relatórios
Requisitos mínimos
- Versão do SO/LibreOffice;
- Etapas reproduzíveis enumeradas;
- Anexos simples quando apropriado;
- Resultados observados/esperados.
Bons exemplos
- tdf#85004 - Writer: falha ao clicar no ícone de lembrete na barra de ferramentas de navegação
- tdf#87907 - DIALOG: A visualização da página na caixa de diálogo de impressão é atualizada ao abrir os detalhes da impressão
- tdf#74839 - EDIÇÃO: A posição dos conectores conectados a um grupo não é atualizada ao editar o conteúdo do grupo
Exemplos de relatórios menos bons
Os relatórios podem ser menos do que ideais por vários motivos. Abaixo estão alguns dos problemas comuns:
Parágrafos do Texto
Descrever um relatório de bug em parágrafos de texto é um dos problemas mais comuns. Os desenvolvedores não têm tempo para ler parágrafos de texto. Passos claros, sucintos e enumerados são sempre melhores.
Um Relatório, Cinco Bugs
Um relatório deve só ter um único bug nele. Agrupar bugs ou listar uma lista inteira de problemas com um único documento é totalmente inútil. Para encontrar desenvolvedores para resolver problemas, é melhor dar a eles um único problema para se concentrar. É improvável que eles aceitem um bug que tenha vários problemas listados.
Faltam detalhes/etapas
Todos os relatórios de bugs devem ter no mínimo:
- Seu sistema operacional e versão do LibreOffice;
- Passos claros e reproduzíveis;
- Resultados esperados;
- Resultados observados;
- Um anexo simples quando apropriado.
Adicionando informações supérfluas
Adicionar muitos detalhes extras que não são relevantes é outro problema comum. Exemplos incluem:
- “isto é um bloqueador”;
- uma longa lista de razões pelas quais é um bloqueador;
- “Não consigo usar o LibreOffice por causa desse bug”;
- “LibreOffice é uma droga” (ou qualquer variação disso); e
- Vou começar a usar seu concorrente, a menos que você o conserte.
Anexos Complexos
Os anexos devem ser o mais simples possível. Aproveite o tempo para reduzir seus exemplos ao mínimo. Isso ajuda tremendamente no diagnóstico de problemas.
Assumindo que os contribuidores sabem tudo
Não presuma que os contribuidores sabem do que você está falando. Descreva seus passos claramente, cada passo do caminho.