Sujet : collaboration
-
Une journée de documentation planifiée attire plus de nouveaux contributeurs qu'un appel permanent à l'aide pour la documentation
Hypothèse : un projet qui annonce une journée unique, avec une liste sélectionnée de petits tickets de documentation, des mainteneurs disponibles pour une revue le jour même et l'étiquette good-first-issue sur chaque tâche, reçoit davantage de modifications de documentation fusionnées venant de personnes n'ayant jamais contribué que lorsque la même liste reste ouverte toute l'année ; une comparaison est proposée à partir de l'historique d'un projet.
-
Décrire un changement pour que les relecteurs puissent le relire
Une description de changement énonce le problème, l'approche et ses alternatives, la façon dont il a été testé et ce que les relecteurs doivent examiner ; elle renvoie au ticket et liste les risques et les suites à donner, afin que la relecture commence par la compréhension plutôt que par l'archéologie.
-
Préférer les propositions de modification pour ce qui appartient à autrui
Améliorer le contenu d'un autre contributeur au moyen d'une proposition liée à une révision, lorsque le remplacement direct n'est pas autorisé.
-
Le triage des tickets pour un petit projet : un jeu d'étiquettes fixe et une passe régulière
Le triage consiste à décider, pour chaque nouveau ticket, ce qu'il est, s'il est exploitable et à qui revient le prochain geste. Un vocabulaire d'étiquettes réduit en trois familles (type, statut, domaine) associé à une brève passe à cadence fixe maintient l'honnêteté du gestionnaire de tickets ; les étiquettes par défaut de GitHub (parmi lesquelles bug, enhancement, documentation, duplicate, question, wontfix, good first issue et help wanted) constituent un point de départ exploitable.
-
Reconnaître les contributeurs : un tableau de contributeurs par type de contribution, sans classement
La spécification All Contributors demande une section Contributeurs à un endroit bien visible, sous forme d'un tableau du nom, d'un lien et de la catégorie de contribution, incluant tout type de contribution à tout niveau, l'ordre étant sans importance ; elle recommande de n'exclure personne pour un niveau de contribution perçu comme faible. Le trailer Co-authored-by de Git crédite les coauteurs d'un même commit. Ensemble, ils permettent à un petit projet de créditer la documentation, le triage, la conception et les signalements, pas seulement le code fusionné.
-
Un fichier CONTRIBUTING qui répond aux cinq premières questions d'un nouveau venu
Avant d'écrire du code, une personne souhaitant contribuer se demande : ce changement est-il souhaité, comment le proposer, que doit contenir une pull request, combien de temps avant une réponse, et comment un changement fusionné atteint-il les utilisateurs. Un fichier CONTRIBUTING qui répond à ces cinq questions dans l'ordre, et qui renvoie ailleurs pour le reste, vise à éviter les pull requests qui seraient rejetées pour une question de périmètre ou de tests manquants.
-
Refuser une demande de fonctionnalité sans perdre le contributeur
Un refus qui s'appuie sur un périmètre écrit, arrive rapidement, propose une alternative et clôt le fil est plus bienveillant que le silence, et il permet de garder le demandeur comme contributeur. Les Open Source Guides notent que le fait d'écrire les choses facilite le refus, et qu'une réponse demande rarement plus d'une ou deux phrases.
Lisible par machine : JSON