Como você diz "é de código aberto, envia um patch" para que seja amigável?

Nas respostas de Qual é a réplica canônica de "é código aberto, envie um patch"? , muitas pessoas expressaram a opinião de que simplesmente pedir às pessoas para enviar um patch é arrogante e rude.

Mas parece-me que, como desenvolvedor em qualquer projeto de código aberto, você verá muito mais solicitações de recursos na lista de discussão do que poderia implementar. Portanto, quando um usuário diz: "Gostaria de ver o recurso X", a verdade é que as chances de ele ser implementado são muito pequenas, a menos que eles mesmos enviem um patch. Além disso, às vezes é necessário um pouco de incentivo para transformar um usuário em colaborador.

Por outro lado, você não quer assustar (potenciais) colaboradores por parecer rude.

Então, como você diria "envie correções em vez de solicitar recursos" de maneira amigável?

Atualização: Obrigado por todas as sugestões! Vejo que a maioria deles exige explicações bastante longas. Mas como eu prefiro evitar (a) explicar a mesma coisa todos os dias (leva muito tempo) ou (b) usar trechos que colo no email (torna-se impessoal muito rápido), eu me pergunto: alguém escreveu isso em um documento que eu possa vincular?

(Coisas específicas do projeto, como escrever testes, compilar o código e enviar o patch, ainda precisam ser documentadas, é claro, mas acho que esses problemas técnicos devem entrar no CONTRIBUTING.txt de qualquer maneira.)

Você não

Na medida em que eu estou experimentando, os contribuidores candidatos são mexedores e não enviarão uma solicitação de recurso apenas solicitando-a. Eles normalmente o solicitam com algum nível de participação:

• Não seria legal se [...]? Pode ser possível fazer A, B e C. (Isso é uma isca para: eu não tenho tempo, mas aqui está uma idéia especificada caso você o faça.)
• Aqui está um patch para fazer / aqui está uma correção para [...].
• Estou pensando em escrever um patch para fazer [...] e poderia usar feedback / alguém está interessado em ajudar.
• Etc.

Os codificadores que enviam uma solicitação de recurso imediatamente, geralmente o fazem por um motivo. Alguns deles incluem (e eu sei que os dois últimos acontecem no WordPress, por exemplo):

• Eles estão profundamente envolvidos em outros projetos de código aberto, ou seja, não têm tempo.
• Eles são free-riders e pretendem manter as coisas assim.
• Está muito além do seu nível de habilidade / escrito em um idioma sobre o qual eles não sabem nada.
• Eles usam o software por falta de uma opção melhor e não querem lidar com uma pilha fedorenta de código batsh * t ^ \ b.
• Eles não podem mais ser incomodados porque seus patches anteriores foram ignorados / rejeitados, ou seja, pensam que eles estavam desperdiçando seu tempo.

Mais tipicamente, as solicitações de recursos serão provenientes de usuários finais que não puderam contribuir com o patch, mesmo que quisessem. Especialmente quando enviado fora do sistema de bilhética.

Penso que a sua prioridade mais importante deve ser não adiar colaboradores potenciais / existentes, em vez de tentar recrutar ativamente novos. É extremamente importante, e digo isso por experiência própria. Eu tenho uma maneira estranha de escolher uma nova base de código, que envolve a leitura superficial do código para obter algum nível de compreensão, entrar no sistema de bilhética e corrigir bugs fáceis de aprender para aprender os detalhes internos (e arquivar) novos como eu teste). Ao longo dos anos, inundei alguns projetos com dezenas de tickets e patches. Muitas vezes, esses tickets recebem pouca ou nenhuma atenção oportuna (nem mesmo um reconhecimento, por exemplo, mantenha-o!) - inclusive quando eles vêm com etapas de diagnóstico documentadas e testes de unidade anexados.

Em resumo, você explica que não tem tempo ilimitado para fazer o trabalho deles de graça. (Você pode pular o bit 'de graça') e, para que eles possam contribuir a qualquer momento, não é o seu projeto, é o projeto de todos.

então você diz: "Lamentamos muito, é uma ótima idéia, mas estamos ocupados demais com todo o restante do trabalho, vamos adicioná-lo à lista, mas se você realmente quiser incluir isso, e você gostaria de nos ajudar, contribuindo para o projeto, isso seria maravilhoso.Temos uma documentação para ajudar os caras a fazer alterações no projeto, eles estão aqui, então se você tiver as habilidades e o tempo e quiser nos ajudar, envie-nos um patch com as alterações. Talvez tenhamos que fazer alguns mods quando o recebermos, para que ele se encaixe nos padrões do projeto, mas você estará nos um grande favor, pelo menos, nos dando uma vantagem para este trabalho e nós amaremos você por nos ajudar ".

É claro que, assim que você começar a pedir patches, nunca poderá deixá-los em seu sistema de tickets por muito tempo; se você ganhar muito, estará integrando-os mais do que fazendo o trabalho que costumava fazer. Você pode não gostar disso, mas é necessário se você quiser que os patches continuem chegando.

Seja educado e explique a situação claramente. Que tal algo como:

Obrigado pelo seu feedback. Achamos seu recurso muito interessante, mas, apesar dos nossos esforços para implementar os recursos mais solicitados em nosso produto, não temos tempo suficiente para implementá-los todos. Se você é um desenvolvedor, pode se juntar a nós contribuindo com o projeto, já que é de código aberto.

Veja, você não pode simplesmente dizer "Por que você está me incomodando com seus pedidos? Não estou aqui para trabalhar de graça; se você deseja esse recurso, vá implementá-lo". A pessoa pode não ser desenvolvedor, pode não conhecer o idioma usado para desenvolver o produto etc.

Portanto, em vez de ser rude, você pode sugerir a participação no projeto e também explicar por que você pode não conseguir implementar o recurso.

Outra maneira de não ser rude é não ter que dizer nada. Se você tiver um site em que os usuários do seu aplicativo possam sugerir novos recursos e reportar bugs, convém classificar os itens por prioridade: por exemplo, se um recurso for solicitado por 10.000 usuários e outro for solicitado por apenas 10 , há chances de que o primeiro seja implementado primeiro.

Nesse site, você sempre pode colocar uma sugestão "implemente você mesmo" para os recursos que, após alguns dias ou semanas, não receberam votos suficientes de outros usuários.

Obrigado pelo seu pedido. Nós o adicionamos ao backlog do projeto e o revisaremos em breve.

Observe que, devido ao volume de solicitações, não podemos garantir que todas serão implementadas. Contamos com voluntários. Portanto, se você é um desenvolvedor, considere doar parte do seu tempo e enviar um patch . Caso contrário, saiba que estamos todos trabalhando duro para obter a lista de pendências e atenderemos a sua solicitação o mais rápido possível.

Realmente, isso foi tão difícil?

Bem, em vez de apenas dizer "enviar um patch", você deve elaborar um pouco mais.

• Deixe claro que você não tem tempo para isso agora ou no futuro próximo; portanto, se outros quiserem implementá-lo em breve, não há como fornecer um patch.
• Aproveite o tempo para avaliar o recurso. Se você gosta sinceramente, não há mal em dizer isso. Encorajar as pessoas. Ou se você acha que o recurso é realmente ruim, reserve um tempo para explicar isso.
• Forneça alguma ajuda inicial. Ninguém conhece a base de código como você. Você não tem tempo para fazê-lo, mas provavelmente sabe exatamente como faria e por onde começar. Dentro de 5 a 10 minutos, você pode compartilhar o conhecimento de que outras pessoas precisariam de horas para descobrir. Além disso, isso ajuda a sua imagem geral a prevalecer. Em vez de ter recursos alienígenas ligados ao seu projeto, você pode orientar os contribuidores para uma boa integração.

Aqui está o que eu normalmente digo ...

"Essa é uma sugestão interessante e seria legal se o FooBarLib pudesse fazer isso. Infelizmente, o FooBarLib é apenas um projeto de tempo livre para mim, por isso é improvável que eu consiga fazê-lo em um futuro próximo. Congratulo-me com os envios ao FooBarLib, portanto, se você conseguir implementar isso pessoalmente, sinta-se à vontade para enviar um patch (leia primeiro nossas diretrizes "como contribuir para o FooBarLib").

Além das boas maneiras de dizer "Enviar um patch", forneça também documentação orientada ao desenvolvedor para que outras pessoas que realmente desejam o recurso possam atualizar seu projeto com facilidade. Muitos projetos não são compatíveis com os desenvolvedores e exigem dias, no mínimo, para ler milhares de linhas de código e toneladas de pequenos casos de teste, cutucando diferentes partes do sistema para se acertar.

Se você fornecer ajuda aos possíveis desenvolvedores, eles estarão mais do que dispostos a fornecer ajuda. Isso significa boa documentação de código, boas páginas wiki que explicam o fluxo (ou um bom diagrama UML / quadro branco) e uma maneira fácil de aceitar patches.

Eu realmente amo a maneira como o github incentiva outras pessoas a participarem do projeto. Várias versões do mesmo projeto podem existir em diferentes contas de usuário. Se você não gostar da direção em que estou adotando o projeto, bifurque-o. Você pode enviar solicitações pull facilmente, mas não fica parado esperando que eu as aceite.

Então, minha resposta é frequentemente, apenas bifurque-se.