Comment les contributions à un projet open source doivent-elles être gérées par le (s) propriétaire (s)?

Lors de la gestion d'un projet open source (en utilisant un service comme GitHub), comment réagirait-on aux éléments suivants:

Quelqu'un a aimablement soumis un correctif pour ajouter une nouvelle fonctionnalité ou résoudre un problème. L'une des situations suivantes se produit:

Le code source ne respecte pas une ou plusieurs conventions de dénomination, etc.
Je pense que le code source pourrait être amélioré d'une certaine manière. Peut-être que le même effet peut être obtenu avec une source beaucoup plus simple, ou peut-être qu'une autre fonctionnalité utile serait nécessaire.

Q1. Est-il acceptable pour moi de modifier la source soumise? (est-ce possible sur GitHub?)

Q2. Toutes ces soumissions devraient-elles être rejetées conformément aux directives de soumission?

Q3. Si oui au T2, qu'en est-il d'une idée vraiment soignée qui a été mal mise en œuvre? Est-il acceptable pour moi d'aller de l'avant et de créer le mien?

Je veux encourager la contribution mais en même temps, il est important de maintenir une certaine norme.

open-source github

— Lea Hayes
source

Réponses:

Mettre en place, si ce n'est déjà fait, un document décrivant les standards du projet. Assurez-vous de décrire tout ce que vous jugez important lors de la contribution de code à votre projet.

Ensuite, répondez à la personne qui a fourni le code en précisant que vous appréciez beaucoup la contribution et que vous souhaitez inclure le correctif, mais il y a quelques problèmes. Fournissez un lien vers le document et citez les problèmes particuliers que vous voyez. Ensuite, demandez à cette personne de résoudre les problèmes et de renvoyer le code.

— Jeremy Heiler
source

Je pense que le noyau Linux a une sorte de zone "changements qui nécessitent des améliorations" pour ce scénario.

— seppo0010

À long terme, cela bénéficiera au projet et à la communauté dans son ensemble si vous amenez les gens à améliorer leurs propres soumissions. Mais il est absolument acceptable de réimplémenter la fonctionnalité vous-même, à condition que vous soyez poli à ce sujet.

— David Schwartz

J'ai vu pas mal de projets qui automatisent certaines de ces choses chaque fois que vous demandez un pull.

— Andrew T Finnell

Juste une note pour ceux qui utilisent GitHub, si vous nommez le document référencé ci CONTRIBUTING- dessus , alors un lien vers ce document s'affichera lors de la soumission d'une demande de pull. Cela peut vous aider à gagner du temps dès le départ si les gens peuvent résoudre eux-mêmes les problèmes courants.

— Michael Mior

S'il n'y a pas trop de contributeurs et que cette contribution est assez précieuse, vous pouvez accepter le correctif tel quel, puis, dans le prochain commit, en réécrire vous-même des parties ou le reformater pour le confirmer selon les normes de codage. - Ensuite, vous enverriez un e-mail au contributeur, avec un lien vers un diff des modifications que vous avez apportées. Espérons que le contributeur étudiera ensuite la différence et soumettra un meilleur patch la prochaine fois, que vous n'avez pas besoin de modifier.

Cela peut être une bonne idée si vous n'avez pas encore écrit de guide du contributeur ou de document de style de codage . En fait, vous pouvez continuer de cette manière (accepter et modifier les correctifs, renvoyer les liens par e-mail aux diffs) pendant un certain temps, jusqu'à ce que vous ayez remarqué les erreurs commises par la plupart des contributeurs. Et puis, vous n'incluez que ces erreurs dans un Guide des contributeurs et un Guide de style .

Si vous faites les choses de cette manière, les réponses à Q1-Q3 seraient:

Q1: Oui, modifiez la soumission, lors d'une validation ultérieure
Q2: Sans objet (je suppose que vous n'avez pas encore rédigé de directives)
Q3: Dites merci et réécrivez-le :-) (Il est peut-être inutile d'appliquer un correctif du tout, si, lors du prochain commit, vous le réécrivez complètement de toute façon)

— KajMagnus
source