De quem é a responsabilidade de corrigir um bug?

Uma situação que surgiu várias vezes em projetos de código aberto é assim:

1. Percebo um bug em nossa implantação e descubro um patch de hack rápido. (Por exemplo, basta comentar o código que realmente não precisamos.)
2. Eu gasto um pouco de esforço extra para descobrir o bug real, criar um patch e enviá-lo por meio de uma solicitação pull do Git ou similar.
3. Minha solicitação de recebimento é rejeitada. Talvez o patch fosse imperfeito (por exemplo, incluísse linhas que não deveria ter), talvez tenha violado o estilo de codificação, talvez tenha outras ramificações. Ou talvez eu tenha feito algo errado no Git - a solicitação de recebimento deveria ter sido reformulada ou algo assim. Um mantenedor fornece feedback sobre como melhorar o patch e solicita que eu o reenvie.

Neste ponto, estou confuso sobre até onde devo proceder. No que me diz respeito, não tenho um problema: eu o corrigi na etapa 1. Eu relatei o problema, até tomei medidas para corrigi-lo para outras pessoas. Mas não acho que seja "minha" solicitação de recebimento, portanto, não sinto que a responsabilidade de melhorar o patch seja de minha responsabilidade.

Uma situação em particular que me incomoda é após a discussão sobre as falhas do meu patch, chegamos a um acordo em uma lista de correspondência sobre qual seria o patch correto (ou seja, como ele deveria se comportar, às vezes incluindo todas as linhas de código explicitadas). Ainda, presume-se que seja minha responsabilidade gerar e enviar o patch.

Existe uma etiqueta padrão nessas situações? Como eles são resolvidos? Minha reação é incomum? Até onde você espera que a correção de bugs seja aceita?

(Observe que quando digo "projeto de código aberto", alguns deles são muito pequenos, mas podem não ser hobbies - simplesmente pequenos projetos de software que são úteis para várias organizações, que comprometem recursos de desenvolvedores para trabalhar neles. Caso a resposta óbvia é "consertar o patch e reenviar", entenda que tenho responsabilidades com meu empregador em trabalhar com coisas que sejam benéficas para ele. Passar um tempo consertando um bug que não nos afeta seria errado ...)

No que me diz respeito, se você encontrar um bug ou tiver uma solicitação de aprimoramento, não for um colaborador do projeto e tiver enviado um relatório de defeitos pelos canais apropriados, está pronto. Em termos de retribuição à comunidade, qualquer pessoa que esteja usando um projeto de código aberto e encontre um defeito deve denunciá-lo.

Tentar encontrar uma solução, projetá-la e implementá-la é um bônus para o projeto. Se você fez isso, pode ser uma boa ideia enviá-lo, por meio de uma solicitação pull ou, talvez, enviando deltas de arquivo para a equipe de desenvolvimento, juntamente com o relatório de defeitos ou a solicitação de aprimoramento para fornecer algo para trabalhar. No entanto, eles não têm nenhuma obrigação de aceitar sua contribuição para o projeto.

Esperar que um usuário contribua com patches parece errado para mim. É bastante fácil participar de uma discussão sobre um problema, mas é um investimento de tempo muito maior para encontrar uma solução. Nenhum projeto deve esperar que os não contribuintes se tornem colaboradores apenas para corrigir um único problema.

Prossiga até onde você estiver disposto a atendê-lo. Seria bom consertar seu patch e compartilhá-lo com o mundo no porta-malas principal, mas se o mantenedor não o quiser, dê de ombros. Você pode postar em algum lugar o seu problema e o patch para lidar com ele, para que outras pessoas no mesmo barco possam procurar uma solução.

E você não está sem problemas. Seu patch não estará na próxima atualização. Então você terá que repetir o processo e torcer para que funcione ou massageie-o no lugar, sempre que você pegar uma nova versão. Portanto, inseri-lo no projeto principal economizará tempo de você e sua empresa a longo prazo.

É uma dor para você, mas você está contribuindo para a comunidade. Eu certamente aprecio todos os colaboradores que contribuem. Não é como um software de qualidade, apenas magicamente gênese das massas. Alguém tem que fazer o trabalho. (Então, quem é incrível? Você é incrível). Se você não estiver disposto, anuncie à comunidade que, embora aprecie a discussão de como deve ser, você está ocupado demais para fazê-lo. Quero dizer, o que eles vão fazer? Cortar seus salários?

Há um princípio que facilita a compreensão da cultura de código aberto: a pessoa que faz o trabalho decide no que trabalhar. Este é um dos seus apelos em comparação com os trabalhos diários dos desenvolvedores. Sua prioridade nº 1 pode ser a nº 50 na lista de pendências. Se você não corrigir sua solicitação de recebimento, eventualmente ela provavelmente chegará ao topo e eles cuidarão dela. No entanto, se você facilitar o suficiente para eles, eles cuidarão disso agora.

O outro motivo pelo qual eles solicitam que você corrija sua solicitação de recebimento é mais magnânimo. Eles querem que você obtenha crédito por sua contribuição, por menor que seja. Se você fizer a correção, seu nome será aquele no campo autor da confirmação. A maioria das pessoas se orgulha de sua contribuição e deseja vê-la, então o modus operandi padrão dos mantenedores é deixá-las.

No que diz respeito à sua responsabilidade para com o empregador, se sua empresa depende desse código, você não está prestando um desserviço a eles. Os empregadores sabem o benefício de um trabalhador que leva tempo para afiar suas ferramentas.

AFAIK, a maneira de código aberto é que a responsabilidade de corrigir bugs é deixada para quem se importa o suficiente com o bug para lidar com a carga e garantir que ele seja corrigido. Dependendo das circunstâncias, eu fiz de tudo, desde simplesmente ignorando um problema até a batalha (fornecendo patches e argumentando para que eles sejam aceitos) para garantir que ele fosse corrigido.

Está tudo certo, apenas não permita que as pessoas que gerenciam o projeto esperem algo errado de você (ou seja, espere que você corrija o problema adequadamente com opções de discussão e depois não faça nada); elas provavelmente estão cientes de mais problemas do que pensam. podem cuidar de si mesmos e tentarão contribuir com você regularmente, se puderem.

O bug original pode apenas afetá-lo, por isso é muito do seu interesse receber o envio, fazendo o que for necessário para colocar seu patch em conformidade. Caso contrário, a próxima versão que você puxar (porque você precisa de outras correções) estará ausente.

Você não deseja manter uma lista de patches que precisa aplicar toda vez que obtém uma nova cópia do projeto - isso é demais. Reserve um tempo extra e conserte-o permanentemente para não precisar lidar com isso novamente.

Para um desenvolvedor de código aberto, existem dois tipos de problemas:

• (a) problemas sem patch
• (b) problemas causados ​​por um patch

Eu acho que a maioria dos mantenedores / desenvolvedores de pacotes de código aberto AMA a idéia de ajudar a obter um contribuidor que não seja essencial para atualizar seus patches.

Seu objetivo principal, no entanto, é minimizar o número de problemas do tipo b. É por isso que a barra está bem alta.

Algumas pessoas superam isso. Eles se tornam colaboradores, ou talvez até colaboradores principais. Outros desistem. Existe uma certa natureza darwiniana no código aberto - a sobrevivência do mais apto.

Encorajo-vos a continuar e cuspir sua contribuição ao ponto em que a equipe a aceitar. Depois de fazer algumas contribuições, elas confiarão em você ainda mais, mas você ainda deve garantir que suas contribuições sejam impecáveis.

O resultado final vale totalmente a pena. Coisas como poder dizer "Eu codifico? Sim ... Você está executando algo que escrevi todos os dias".