Triagem de bugs e curadoria de problemas #

O rastreador de problemas é importante para a comunicação no projeto porque serve como local centralizado para fazer solicitações de recursos, relatar bugs, identificar os principais projetos nos quais trabalhar e discutir prioridades. Por esse motivo, é importante organizar a lista de problemas, adicionando rótulos aos problemas e encerrando os problemas resolvidos ou não solucionáveis.

A triagem de problemas não requer nenhum conhecimento específico nas partes internas do Matplotlib, é extremamente valiosa para o projeto e convidamos qualquer pessoa a participar da triagem de problemas! No entanto, pessoas que não fazem parte da organização Matplotlib não têm permissão para alterar marcos, adicionar rótulos ou fechar problemas . Se você não tiver permissões GitHub suficientes para fazer algo (por exemplo, adicionar um rótulo, fechar um problema), deixe um comentário marcando @matplotlib/triageteamcom suas recomendações!

Trabalhando em problemas para melhorá-los #

Melhorar os problemas aumenta suas chances de serem resolvidos com sucesso. Diretrizes sobre o envio de bons problemas podem ser encontradas aqui . Um terceiro pode fornecer feedback útil ou até adicionar comentários sobre o problema. As seguintes ações são normalmente úteis:

documentando problemas que estão faltando elementos para reproduzir o problema, como amostras de código

sugerindo um melhor uso da formatação do código (por exemplo, back ticks triplos na remarcação).

sugerindo reformular o título e a descrição para torná-los mais explícitos sobre o problema a ser resolvido

vincular a questões ou discussões relacionadas enquanto descreve brevemente como eles estão relacionados, por exemplo "Veja também #xyz para uma tentativa semelhante" ou "Veja também #xyz onde a mesma coisa foi relatada" fornece contexto e ajuda na discussão

verificando se o problema é reproduzível

classifique o problema como uma solicitação de recurso, um bug antigo ou uma regressão

Equipe de triagem #

Se você gostaria de se juntar à equipe de triagem:

Faça a triagem correta de 2 a 3 problemas.
Peça a alguém da equipe de triagem (em público ou em particular) para recomendá-lo à equipe de triagem. Se você trabalhou com alguém sobre o assunto triado, essa pessoa seria uma boa pessoa para perguntar.
Exercite com responsabilidade seu novo poder!

Qualquer pessoa com direitos de confirmação ou triagem também pode nomear um usuário para ser convidado a ingressar na equipe de triagem.

Operações de triagem para membros das equipes principais e de triagem #

Além do acima, os membros da equipe principal e da equipe de triagem podem realizar as seguintes tarefas importantes:

Atualizar rótulos para problemas e PRs: consulte a lista de rótulos github disponíveis .
Problemas de triagem:
- reproduza o problema , se o código postado for um bug, rotule o problema com "status: bug confirmado".
- identificar regressões , determinar se o bug relatado costumava funcionar como esperado em uma versão recente do Matplotlib e, em caso afirmativo, determinar a última versão de trabalho. As regressões devem ser marcadas para o próximo lançamento de correção de bug e podem ser rotuladas como "Versão crítica".
- feche as perguntas de uso e educadamente aponte o repórter para usar discurso ou Stack Overflow e rotule como "suporte da comunidade".
- feche os problemas duplicados , depois de verificar se eles são realmente duplicados. Idealmente, o remetente original move a discussão para o problema duplicado mais antigo
- feche questões que não podem ser replicadas , depois de deixar tempo (pelo menos uma semana) para adicionar informações extras

Um fluxo de trabalho típico para problemas de triagem #

O seguinte fluxo de trabalho [ 1 ] é uma boa maneira de abordar a triagem de problemas:

Agradeça ao repórter por abrir um problema

O rastreador de problemas é a primeira interação de muitas pessoas com o próprio projeto Matplotlib, além de apenas usar a biblioteca. Como tal, queremos que seja uma experiência acolhedora e agradável.
Esta é uma questão de uso? Nesse caso, feche-o com uma mensagem educada.
As informações necessárias são fornecidas?

Verifique se o pôster preencheu o modelo de edição. Se informações cruciais (a versão do Python, a versão do Matplotlib usada, o sistema operacional e o back-end) estiverem faltando, peça educadamente ao postador original para fornecer as informações.
O problema é mínimo e reproduzível?

Para relatórios de bugs, pedimos que o relator forneça um exemplo reproduzível mínimo. Veja esta postagem útil de Matthew Rocklin para uma boa explicação. Se o exemplo não for reproduzível, ou se claramente não for mínimo, sinta-se à vontade para perguntar ao repórter se ele pode fornecer um exemplo ou simplificar o fornecido. Reconheça que escrever exemplos reprodutíveis mínimos é um trabalho árduo. Se o repórter estiver com dificuldades, você mesmo pode tentar escrever um.

Se um exemplo reproduzível for fornecido, mas você vir uma simplificação, adicione seu exemplo reproduzível mais simples.

Se você não conseguir reproduzir o problema, informe-o junto com as versões do seu sistema operacional, Python e Matplotlib.

Se precisarmos de mais informações desta ou da etapa anterior, marque o problema com "status: precisa de esclarecimento".
Isso é uma regressão?

Embora nos esforcemos para ter uma biblioteca livre de bugs, as regressões são a prioridade mais alta. Se quebrarmos o código do usuário que costumava funcionar, devemos corrigi-lo na próxima versão do patch!

Tente determinar quando a regressão ocorreu executando o código de reprodução em versões mais antigas do Matplotlib. Isso pode ser feito por versões lançadas do Matplotlib (para obter a última versão em que funcionou) ou usando git bisect para encontrar o primeiro commit onde ele foi quebrado.
Este é um problema duplicado?

Temos muitas questões em aberto. Se um novo problema parecer duplicado, aponte para o problema original. Se for uma duplicata clara ou se houver consenso de que é redundante, feche-a. Certifique-se de agradecer ao repórter e incentivá-lo a comentar o problema original e, talvez, tentar corrigi-lo.

Se o novo problema fornecer informações relevantes, como um exemplo melhor ou um pouco diferente, adicione-o ao problema original como um comentário ou edite a postagem original.

Rotule o problema fechado com "status: duplicado"
Certifique-se de que o título reflita com precisão o problema. Se você tiver as permissões necessárias, edite você mesmo se não estiver claro.
Adicione os rótulos relevantes, como "Documentação" quando o problema for sobre documentação, "Bug" se for claramente um bug, "Novo recurso" se for uma solicitação de novo recurso, ...

Se o problema estiver claramente definido e a correção parecer relativamente direta, rotule o problema como “Bom primeiro problema” (e possivelmente uma descrição da correção ou uma dica de onde procurar na base de código para começar).

Uma etapa útil adicional pode ser marcar o módulo correspondente, por exemplo, o rótulo "GUI/Qt" quando relevante.

Trabalhando em PRs para ajudar a revisar #

A revisão do código também é incentivada. Colaboradores e usuários são bem-vindos a participar do processo de revisão seguindo nossas diretrizes de revisão .

Agradecimentos #

Esta página é levemente adaptada do projeto scikit-learn .