Comment utiliser les modèles de relations publiques GitHub

Si vous faites un travail – qu’il soit open source ou fermé – (bien que je sache que la plupart de ceux qui lisent ce site sont impliqués dans l’open source), vous utilisez probablement un contrôle de source, et c’est probablement GitHub.

Pour beaucoup d’entre vous, vous suivez un projet, contribuez à un projet ou gérez des pull requests à un projet. Et qu’en est-il des projets sur lesquels vous travaillez en équipe ?

Peut-être que votre flux de travail ressemble à ceci :

• vous créez une branche pour travailler sur une fonctionnalité,
• vous poussez la branche pour détailler le travail que vous avez fait pour qu’un pair l’examine,
• l’avis est fusionné,
• continue.

Mais que mettez-vous dans le modèle de pull request ? Est-ce la même chose à chaque fois ou est-ce différent? Qu’en est-il si le contenu du PR est lié à quelque chose dans Trello, Asana, Basecamp ou un autre système de gestion de projet ?

C’est là que les modèles GitHub PR entrent en jeu.

Modèles de relations publiques GitHub

Vous pouvez tout lire à leur sujet sur la page, mais voici l’essentiel (sans jeu de mots):

Il est difficile de résoudre un problème lorsqu’il manque des détails importants. Désormais, les responsables de projets peuvent ajouter des modèles pour les problèmes et les demandes d’extraction aux projets, aidant ainsi les contributeurs à partager les bons détails au début d’un fil de discussion.

Et l’idée est simple : nous créons des modèles pour les problèmes et les demandes d’extraction pour les autres qui fournissent un niveau d’informations qu’ils doivent remplir avant de soumettre un problème ou une demande d’extraction.

Cela nous aide, car les mainteneurs connaissent toutes les informations dont nous avons besoin avant de les examiner. De plus, cela peut nous permettre d’établir un lien vers un problème précédent, un ticket précédent, avant tout ce qui concerne le projet.

Par exemple, supposons que vous travaillez sur un projet et que vous souhaitez inclure les informations suivantes :

• une courte description de ce que le PR fait pour que le mainteneur n’ait pas à deviner,
• le statut du PR indiquant s’il doit être prêt à être fusionné ou s’il est encore en développement mais prêt pour une révision,
• un lien vers le ticket dans votre gestionnaire de projet auquel le PR est pertinent.

Je ne dis pas que ce sont les informations requises, mais c’est quelque chose que nous avons utilisé et que j’ai trouvé utile (et c’est bien de voir que d’autres améliorations sont apportées au fil du temps ).

Mais comment l’utilisons-nous ?

Le site est assez clair, mais c’est vraiment simple. Vous avez besoin des fichiers suivants dans votre répertoire de projet ou dans le dossier. répertoire github :

• ISSUE_TEMPLATE
• PULL_REQUEST_TEMPLATE

Chacun d’entre eux devrait être des fichiers de démarquage qui expliquent exactement ce que vous recherchez pour vos contributeurs à inclure chaque fois qu’ils contribuent à votre projet d’une manière ou d’une autre.

Et puis, chaque fois qu’un utilisateur cherche à signaler un problème ou à créer une demande d’extraction, il reçoit les informations du modèle.

Nice, n’est-ce pas?

Ce n’est pas grand-chose, mais…

Vous pensez peut-être que ce n’est pas grand-chose, mais il est assez facile d’aider à améliorer la qualité des informations entrant dans un projet, de faire réfléchir vos contributeurs à ce qu’ils mettent dans le projet, puis de réagir en conséquence.

De plus, cela vous aide, ainsi que le reste de votre équipe, à comprendre ce qui est sur le point d’être examiné et à vous préparer à tout changement qui pourrait survenir lorsque vous travaillez sur ces projets.