O que fazer com problemas abandonados no GitHub?

Este é um dilema: você não pode fechar o problema como "consertado", porque você não sabe se ele foi corrigido, ou pelo menos mesmo se algum problema foi corrigido, você não sabe realmente se este era o assunto que o repórter estava falando. Por outro lado, você não quer deixar um problema que pode ter sido corrigido, especialmente se você nunca conseguirá fechá-lo, porque você nunca receberá uma confirmação.

Então, você deve fechá-lo, mas provavelmente não como "fixo". Você poderia inventar uma razão de fechamento personalizada "maybefixed" ou "unconfirmedfix" se você quiser ser positivo ou "reportervanished" se não quiser. Você também pode simplesmente dizer "não foi possível reproduzir" e esperar que o mesmo bug apareça para um repórter mais responsivo.

No entanto, você não deve gastar recursos em um bug para o qual você nunca saberá se ele foi realmente corrigido ou não.

Sua pergunta principal já foi respondida, mas você também perguntou sobre a documentação do processo e isso também precisa ser respondido.

A solução que vi em muitos projetos não é colocá-lo no README.md do projeto, mas em uma contribuição especial README - um arquivo README para os contribuidores. Este arquivo descreve tudo o que você quer que as pessoas que contribuem para o seu projeto saibam - seja sobre o código (convenções de nomenclatura, organização de módulos, etc.) ou sobre o processo (como escrever commits, como manipular tickets etc.). Esse arquivo pode ser outro arquivo .MD no projeto ou colocado em um repositório totalmente diferente (para que possa ser compartilhado entre todos os seus projetos). Apenas não esqueça de criar um link para ele a partir do principal README.md !

O ponto de separar essa informação do README principal é que geralmente apenas uma fração do usuário do projeto contribui diretamente para ela. A maioria dos usuários não precisa ficar entediada com essa informação - eles precisam apenas saber o que o seu projeto faz e como usá-lo, e é isso que o README principal deve conter. No caso do seu projeto, a seção contribuição é muito pequena para não sobrecarregar o README principal - mas se você documentar todos os fluxos de trabalho que você quer que os contribuidores sigam, ele não caberá mais. .

Note que qualquer usuário pode abrir um bug, então se você tiver requisitos especiais sobre a abertura de um bug você deve colocá-los no README principal (tente manter o shede embora - diferentemente dos contribuidores de código, os repórteres estarão menos dispostos a ir a grandes comprimentos para estudar e se adequar às suas regras). No entanto, a pessoa que realmente corrige o bug e fecha o ticket (seja você ou um dos contribuintes que você confirmou) é um contribuidor direto e pode-se esperar que leia a contribuição README - assim, o processo de fechar tíquetes quando o repórter não não responder deve ser descrito lá.

Eu li isso como mais uma pergunta sobre as práticas sobre como lidar com um bug não verificado (usando o rastreador de problemas do github) do que qualquer outra coisa.

Para mim, essa é uma resposta direta com base em outros rastreadores de problemas que usei. O Github não força ninguém a usar nenhum fluxo de trabalho, o que o torna muito flexível ... e inútil na sua configuração padrão.

Olhando para o fluxo de trabalho padrão do Bugzilla, obtemos:

Euvouapontarumacoisamuitoimportantelá-eleéresolvidocomocorrigidoantesdeserfechadoapósser>verificado.OfluxodetrabalhobásicodoGithubmostraapenasosestadosvermelho(aberto)everde(fechado).

Assim,umaabordageméusarosrótulosdentrodoGithub( rótulos do seu aplicativo ) para tentar mostrar as informações adicionais. Você pode criar um par de rótulos "não verificados" e "verificados" para serem aplicados depois de fechar o problema. Observe que essa é apenas uma abordagem - se você pesquisar, poderá encontrar dezenas de abordagens diferentes para o uso de rótulos. Aqui, a pergunta Como gerenciar problemas do github para (prioridade, etc)? aborda isso.

Você consertou, do ponto de vista do desenvolvedor, está feito. Feche o problema no Github. Aplique o rótulo 'não verificado' a ele. Quando alguém familiarizado com o bug da versão anterior disser "sim, isso corrigiu", você poderá alterar o rótulo para "verificado". Se eles disserem que não, você reabre.

Note também que existem outros estados resolvidos além de 'fixo'. Existe 'wontfix' (a correção é algo que simplesmente não pode ser feito com a estrutura atual) e 'worksforme' (o bug não pode ser reproduzido) e 'invalid' (você está arquivando um bug sobre o sistema operacional, não as coisas do tipo de aplicativo).

Eu tomaria uma das duas visões, dependendo de como estava confiante de que estava falando sobre a mesma coisa que o repórter original:

1) Já que o repórter não está mais disponível, considere que o bug em questão significa o que quer que você tenha corrigido. Se isso ajudar, anexe os casos de teste para esclarecer quais falhas você encontrou. Descreva detalhadamente no relatório de bug o que foi corrigido e deixe uma nota como: "Acredito que isso é o que 'nav breaks' significa, reabra ou crie um novo bug se não for o que você quis dizer". Marque o bug como corrigido.

2) Já que o repórter não está mais disponível, julgue que o bug não pode ser reproduzido (sabidamente), já que apenas a palavra do repórter confirmaria que é a mesma coisa que eles relataram. Levante um novo bug para descrever o que você consertou, por uma questão de crédito mencionar que foi observado sob as condições descritas pelo repórter ausente, note que ambos em poderão ser duplicados, marcar o novo bug fixo e marcar este inválido ou não reprodutível com uma nota como: "Eu não posso descobrir o que você quis dizer com 'quebra nav', mas eu resolvi o problema que eu encontrei. Por favor, reabra ou crie um novo bug se a nav continua a quebrar, descrevendo com mais detalhes o que está errado ".

Quanto à escala de tempo, acho que isso deve depender do projeto. Se você for muito responsivo e estiver lidando com esse bug poucos dias depois de ser gerado, as pessoas devem entender que você não esperará semanas por uma resposta antes de resolver o problema. Por outro lado, se estiver em seu slushpile por meses, ele poderá ficar aberto por mais um mês ou dois sem causar nenhum problema.

Por esse motivo, não acho que exista um limite de tempo específico que constitua "boa prática" ou que você precise publicar sua política e cumpri-la. Certamente você não gostaria de registrar que o repórter não pode ser contatado até que você tenha feito um esforço para contatá-los. Mas eu também não vejo nenhum ponto deixando vários avisos contando até um prazo: ou eles revisitarão o bug e quererão dizer algo, ou não o farão.