Como as contribuições para um projeto de código aberto devem ser gerenciadas pelo (s) proprietário (s)?

Ao gerenciar um projeto de código aberto (usando um serviço como o GitHub), como alguém responderia ao seguinte:

Alguém enviou um patch para adicionar um novo recurso ou solucionar um problema. Qualquer uma das seguintes situações ocorre:

O código fonte não atende a uma ou mais convenções de nomenclatura etc.
Eu sinto que o código fonte poderia ser melhorado de uma certa maneira. Talvez o mesmo efeito possa ser alcançado com fontes muito mais simples, ou talvez outro recurso útil seja necessário.

Q1 É aceitável alterar a fonte enviada? (isso é possível no GitHub?)

Q2 Todos esses envios devem ser rejeitados de acordo com as diretrizes de envio?

Q3 Se sim ao Q2, que tal uma idéia realmente interessante que foi mal implementada? É aceitável que eu vá em frente e crie o meu?

Quero incentivar a contribuição, mas ao mesmo tempo é importante manter um certo padrão.

open-source github

— Lea Hayes
fonte

Respostas:

Configure, se ainda não o fez, um documento que descreva os padrões do projeto. Certifique-se de descrever tudo o que você acha importante ao contribuir com código para o seu projeto.

Em seguida, responda à pessoa que forneceu o código detalhando que você aprecia muito a contribuição e que gostaria de incluir o patch, mas existem alguns problemas. Forneça um link para o documento e cite os problemas específicos que você vê. Em seguida, peça a essa pessoa que corrija os problemas e reenvie o código.

— Jeremy Heiler
fonte

Eu acho que o kernel do linux tem algum tipo de área de "mudanças que precisam de melhorias" para esse cenário.

— seppo0010

A longo prazo, beneficiará o projeto e a comunidade como um todo, se você conseguir que as pessoas melhorem seus próprios envios. Mas não há problema em reimplementar o recurso, desde que você seja educado.

— David Schwartz

Eu já vi alguns projetos que automatizam algumas dessas coisas sempre que você solicita um pull.

— Andrew T Finnell

Apenas uma observação para aqueles que usam o GitHub, se você nomear o documento mencionado acima CONTRIBUTING, um link para este documento será exibido ao enviar uma solicitação pull. Pode ajudar a economizar algum tempo se as pessoas puderem resolver problemas comuns por conta própria primeiro.

— Michael Mior 03/03

Se não houver muitos colaboradores, e essa contribuição for bastante valiosa, você poderá aceitar o patch como está e, no próximo commit, reescrever partes dele ou reformatá-lo para confirmar os padrões de codificação. - Depois, você enviaria um email para o colaborador, com um link para uma comparação das alterações feitas. Espero que o colaborador estude o diff e envie um patch melhor na próxima vez, que você não precisa alterar.

Essa pode ser uma boa ideia, se você ainda não escreveu nenhum documento Guia de colaboradores ou Estilo de codificação . De fato, você pode continuar dessa maneira (aceitar e alterar patches, enviar e-mails com links para diffs) por um tempo, até perceber os erros que a maioria dos colaboradores faz. E então você inclui apenas esses erros no Guia do contribuidor e no Guia de estilo .

Se você fizer as coisas dessa maneira, as respostas para Q1-Q3 seriam:

T1: sim, edite o envio em um commit subsequente
P2: Não aplicável (presumi que você ainda não tenha escrito diretrizes)
Q3: agradeça e reescreva-o :-) (Talvez seja inútil aplicar um patch, se, no próximo commit, você o reescrever completamente)

— KajMagnus
fonte