Comment gérer les contributeurs open source bien intentionnés?

Si un programmeur vous contacte et vous demande de contribuer à votre projet, comment le gérez-vous?

Vous ne savez pas si ce gars est bon. Peut-être qu'il aura plus de problèmes qu'il n'en vaut.
Il pourrait essayer d'attacher son nom à un projet réussi juste pour les félicitations.
Il pourrait essayer de prendre le projet dans une direction que vous ne voulez pas vraiment, en ajoutant des fonctionnalités que vous pensez ne valent pas la complexité supplémentaire.
Ou, il pourrait être un contributeur très utile. Tu ne sais pas.

Comment gérez-vous de telles demandes de personnes que vous ne connaissez pas (sur GitHub, en particulier, si cela fait une différence)? Quelle est l'étiquette ici?

open-source github

— Solo
source

sur github, laissez-le simplement faire une demande de retrait et rejeter si vous ne l'aimez pas

— ratchet freak

Nom de compte approprié?

— Aren

Je pense que ce à quoi vous faites référence est un statut de «contributeur» actif. En bref: ne faites pas de quelqu'un un contributeur à quelque chose auquel il n'a pas encore contribué. Les projets Open Source ont l'avantage que n'importe qui peut simplement y travailler, alors laissez-le faire, puis décidez.

— poke

@Aren ai-je un supplément +=1pour ça?

— Solo

Réponses:

L'appartenance à un projet OSS n'est pas la même chose qu'une équipe corporative financée où les gens sont interviewés et choisis. La source est déjà là-bas (ce n'est pas open source sinon). Dites-leur d'envoyer des correctifs. Si ce sont de bons correctifs (et vous devez d' abord les revoir), validez-les. Une fois que le prospect a gagné en confiance et a fait des contributions précieuses, donnez-lui un accès en écriture.

Les équipes OSS se développent de manière organique. Rendez-vous disponible pour poser des questions et laissez-les accumuler de la crédibilité dans la rue au fil du temps.

— Michael
source

+1. Les correctifs sont la meilleure façon de commencer car ils créent la barrière d'entrée la plus basse pour commencer. Si la personne commence à fournir plus de correctifs (ou devient un contributeur régulier), il est plus rapide / plus facile de passer aux demandes d'extraction.

— Evan Plaice

Excusez mon ignorance, mais y a-t-il une différence entre un Patch et une Pull Request?

— heltonbiker

Pourquoi ne pas laisser cette personne impatiente vous envoyer une demande de pull? Vous aurez l'occasion de revoir et de critiquer le code de cette personne. Cela semble être la solution la plus simple.

— duggiefresh
source

N'est-ce pas ainsi que GitHub est censé fonctionner?

— alroc

La seule chose que j'ajouterais est de demander à cette personne que la première demande de tirage soit quelque chose de petit, pour éviter qu'elle y consacre trop d'efforts avant que vous puissiez voir son code. Face à un "défi" comme celui-ci, ils peuvent se sentir obligés de soumettre quelque chose de grand et impressionnant :-)

— Krzysztof Kozielczyk

et quelque chose de grand et impressionnant cassera des trucs s'il n'est pas manipulé avec soin

— cliquetis freak

Donc, si la contribution est utile, mais manque de qualité et que vous êtes trop occupé pour le tenir dans la main, est-il acceptable de simplement rejeter la contribution?

— Solo

@Solo: Certainement. Il est également normal d'attendre / demander au contributeur de maintenir et de corriger les bogues dans sa fonctionnalité, au moins jusqu'à ce que le reste de l'équipe apprenne ce code, et en particulier pour les commits plus importants.

— Hugo

Acceptez et examinez les modifications de sa part à titre provisoire. Donnez-lui un accès en écriture au référentiel de code source lorsqu'il aura fait ses preuves.

— Robert Harvey
source