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 problemas são registrados no Bugzilla
Todos os cães podem ir para o céu
, mas algumas questões devem ser acompanhadas fora do Bugzilla. Entre elas estão:
| Localização ou categoria do problema | Onde reportar |
|---|---|
| Extensões do LibreOffice | Com o autor da extensão |
| Infraestrutura do TDF/LibreOffice (sites, listas de discussão, etc.) | Redmine |
| Construindo o LibreOffice | Lista de email do desenvolvedor |
| Testes unitários do LibreOffice | Lista de email do desenvolvedor |
| Palavras que não constam nos dicionários | Ao responsável pelo dicionário ou pelo repositório |
| Erros nas traduções | É permitido relatá-los no Bugzilla, mas é mais eficiente adicioná-los como sugestões no Weblate (não é necessário se cadastrar) |
Antes de relatar um problema
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.
Considere dar uma olhada em Primeiros passos a seguir antes de relatar um bug, especialmente no caso de bugs relacionados a fontes, gráficos, apresentações de slides e cálculos.
Se você se deparar com algo que possa ser um bug, mas que talvez seja apenas algo que você não compreende, pode consultar a lista de discussão dos usuários do LibreOffice ou o Ask LibreOffice. Considere ler a documentação do usuário e use o aplicativo o suficiente para se familiarizar com o que ele normalmente faz.
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 à impressão, acesse #Mais informações.
- Depois de tudo isso, se não parecer haver um ticket existente sobre esse problema, siga as instruções a seguir.
Como relatar um problema
Go to Bugzilla.
Entrar
miniatura|Bugzilla - Página principal
Se for solicitado que você faça o login, faça o login com sua conta do Bugzilla.
Se você não tiver uma conta no Bugzilla, crie uma clicando em Nova conta.
Componente
Em Componente, escolha o componente.
Se você não tiver certeza de qual componente está relacionado ao seu problema, selecione o pseudo-componente LibreOffice. Alguém analisará o relatório posteriormente e selecionará um componente mais específico.
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 “Gravidade” e você estiver solicitando um recurso, selecione “melhoria”. Caso contrário, ignore essa opção, a menos que você tenha experiência. Se quiser saber as definições dos itens da seção “Gravidade”, consulte este fluxograma.
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 situação em que você deve alterar o Status para NOVO é se alguém já tiver confirmado o bug em outro lugar (Ask, lista de discussão, algum fórum). Nesses casos, inclua 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 que você publique seu problema nesses canais, seu objetivo deve ser criar um bom relatório de bug no Bugzilla. Esses canais podem ajudá-lo nessa tarefa.
Após relatar um problema
O novo bug aparece com o status “NÃO CONFIRMADO”. Observe que você não deve alterar o status por conta própria, a menos que receba instruções explícitas para tal: mais especificamente, a mudança de “NÃO CONFIRMADO” para “NOVO” só deve ser feita de forma independente quando outra pessoa confirmar o 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:
- Contrate e/ou treine seus próprios desenvolvedores para trabalhar com o LibreOffice. Teremos o maior prazer em orientá-los: consulte as páginas para desenvolvedores.
- Financie pessoas físicas ou jurídicas para trabalhar em questões específicas — consulte a lista de desenvolvedores certificados.
- Entre em contato com a The Document Foundation para obter ajuda caso disponha de um orçamento limitado e deseje colaborar, coordenar ou reunir seus recursos com outros na mesma situação para financiar correções ou melhorias específicas.
Agradecemos cada relatório recebido. Escrever um relatório de bug pode ser tedioso e demorado, mas o tempo que outras pessoas dedicam à análise e, eventualmente, à correção de um problema pode ser dez ou, às vezes, até cem vezes maior em comparação. Por isso, pedimos sua compreensão e que, por favor, forneça mais informações, caso seja solicitado. Além disso, um relatório claro e com informações completas aumenta suas chances de que o problema seja resolvido.
Como comentar sobre os assuntos
Evite postar comentários do tipo “eu também” ou “temos 1.000 licenças aqui e só esse bug nos impede de migrar”, que não trazem nenhuma informação útil adicional. Uma exceção a isso é quando você comenta sobre um bug que ainda não foi CONFIRMADO. Nesse caso, forneça os passos para reproduzir o problema (ou confirme os fornecidos pelo autor original) e altere o status do problema para NOVO. Observe que, se não houver passos claros para reproduzir o problema, ele poderá voltar rapidamente para o status NECESSITA DE INFORMAÇÕES; portanto, é essencial encontrar um cenário de reprodução bom e simples.
Relatórios positivos
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 satisfatórios
Os relatórios podem ser menos do que ideais por vários motivos. Abaixo estão alguns dos problemas comuns:
Um relatório para 5 questões
Relatar vários problemas em um único ticket — mesmo que afetem um único documento — não é a melhor prática, especialmente a longo prazo. Um ticket deve relatar apenas um único problema.
Faltam detalhes/etapas
Todos os relatórios de bugs devem ter no mínimo:
- seu sistema operacional e a versão do LibreOffice;
- passos claros e reproduzíveis;
- resultados esperados;
- resultados observados; e
- um anexo simples, quando for o caso.
Inclusão de informações supérfluas
Adicionar muitos detalhes extras que não são relevantes é outro problema comum. Exemplos incluem:
- “isso é um impedimento”;
- uma longa lista de motivos pelos quais isso é um impedimento;
- “Não consigo usar o LibreOffice por causa desse bug”;
- “O LibreOffice é péssimo” (ou qualquer variação disso); e
- “Vou começar a usar o produto da concorrência, a menos que vocês consertem isso.”
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.
Partindo do princípio de que os colaboradores sabem tudo
Não presuma que os contribuidores sabem do que você está falando. Descreva seus passos claramente, cada passo do caminho.