Como lidar com colaboradores de código aberto bem-intencionados?

Se um programador entrar em contato com você e pedir para contribuir com seu projeto, como você lida com isso?

Você não sabe se esse cara é bom. Talvez ele seja mais problemático do que vale.
Ele pode estar tentando anexar seu nome a um projeto de sucesso apenas pelos elogios.
Ele pode estar tentando levar o projeto em uma direção que você realmente não deseja, adicionando recursos que você acha que não valem a complexidade extra.
Ou ele pode ser um colaborador muito útil. Você simplesmente não sabe.

Como você lida com essas solicitações de pessoas que você não conhece (no GitHub, especificamente, se isso faz alguma diferença)? Qual é a etiqueta aqui?

open-source github

— Solo
fonte

no github apenas deixá-lo fazer uma solicitação de recebimento e rejeitar se você não gostar dele

— aberração catraca

Nome de conta apropriado?

— Aren #

Acho que você pode estar se referindo a um status ativo de "colaborador". Em resumo: não faça de alguém um colaborador de algo para o qual ainda não contribuiu. Os projetos de código aberto têm o benefício de que qualquer um pode trabalhar nele, então deixe-os fazer isso e depois decida.

— cutucar

@ Aren, recebo mais +=1por isso?

— Solo

Respostas:

Ser membro de um projeto OSS não é o mesmo de uma equipe corporativa financiada, na qual as pessoas são entrevistadas e escolhidas. A fonte já está disponível (caso contrário, não é de código aberto). Diga a eles para enviar alguns patches. Se eles são bons patches (e você deve revisá-los primeiro), confirme-os. Quando o cliente em potencial ganhar confiança e um histórico de contribuições valiosas, dê a ele acesso para gravação.

As equipes de OSS crescem organicamente. Sinta-se à disposição para fazer perguntas e permitir que elas acumulem algum crédito nas ruas ao longo do tempo.

— Michael
fonte

+1 isso. Os patches são a melhor maneira de começar, porque eles criam a menor barreira de entrada para começar. Se a pessoa começar a fornecer mais correções (ou se tornar um colaborador regular), será mais rápido / fácil alternar para receber solicitações.

— precisa

Desculpe minha ignorância, mas existe uma diferença entre um Patch e um Pull Request?

— precisa saber é o seguinte

Por que não deixar essa pessoa ansiosa enviar uma solicitação de recebimento? Você terá a oportunidade de revisar e criticar o código dessa pessoa. Esta parece ser a solução mais simples.

— duggiefresh
fonte

Não é assim que o GitHub deve funcionar?

— alroc

A única coisa que gostaria de acrescentar é pedir a essa pessoa que a primeira solicitação pull seja algo pequeno, para evitar que ela gaste muito esforço nela antes que você possa ver seu código. Quando confrontados com um "desafio" como esta, eles podem sentir-se obrigados a apresentar algo grande e :-) impressionante

— Krzysztof Kozielczyk

e algo grande e impressionante vai quebrar coisas se não for tratada com cuidado

— catraca aberração

Portanto, se a contribuição é útil, mas está em falta de qualidade, e você está ocupado demais para segurá-lo com mão, é aceitável rejeitar a contribuição?

— Solo

@ Solo: Certamente. Também não há problema em esperar / pedir ao colaborador que mantenha e corrija bugs em seus recursos, pelo menos até o restante da equipe aprender esse código e, principalmente, para confirmações maiores.

— 307 Hugo

Aceite e revise as alterações dele provisoriamente. Dê a ele acesso de gravação ao repositório de código-fonte quando ele provar seu valor.

— Robert Harvey
fonte