Format des titres de Pull Request - [TAG]

[yannbertrand]

Dans #5445, des débats se sont lancés sur le format que nous souhaitions appliquer.

Voici une première question qui est ouverte à discussion.

Ce tag est pour le moment utilisé uniquement pour générer le CHANGELOG.md de nos projets. Aujourd'hui seulement FEATURE, BUGFIX et TECH se retrouvent dans des catégories spécifiques de ce fichier, tout le reste tombe dans une catégorie ":coffee: Autre".

Dans nos CHANGELOG, on constate parfois l'usage d'autres tags : DOC, CLEANUP, TASK, PERFORMANCE, A11Y, DOCUMENTATON (en plus de DOC), DX, BUG (au lieu de BUGFIX), ADMIN (donc l'app), API, etc...

Il arrive aussi que plusieurs tags soient utilisés comme [BREAKING CHANGES][FEATURE] qui tombe dans la catégorie "Autres".

L'objectif de ce sondage est de trancher sur le cadre qu'on souhaite donner à ces tags pour améliorer la lisibilité de nos Pull Requests.

À vous !

[VincentHardouin]

Dans la liste des tags utilisés on peut voir beaucoup de tags plus spécifique à une catégorie et je trouve pas que ça soit utile : Exemple :

• TECH est un ensemble qui contient PERFORMANCE, CLEANUP, DX, …
• FEATURE est un ensemble qui contient A11Y

Par contre, je pense qu'il manque DOC, mais il n'a pas besoin d'une section dédiée dans le CHANGELOG et BREAKING_CHANGES qui lui devrait en avoir une bien visible et en première place.

[MelanieMEB]

De même que Vincent.

Je serais pour ajouter [DOC] qui a vraiment une catégorie à part.

Pour tout ce qui est CLEANUP, TASK, PERFORMANCE, etc. pour moi c'est dans TECH
Et pour : A11Y, DX, dans FEATURE

Après, si on souhaite préciser Breaking-Change (dans le changelog Pix-UI par exemple), cela peut être possiblement un sous tag.
Exemple :
[TECH][BREAKING-CHANGE] Montée de version.

La catégorie AUTRE risque d'être une catégorie fourre-tout après.

FEATURE si a apporte un changement à l'utilisateur, TECH sinon, BUGFIX si ça corrige une erreur et DOC si ce n'est pas du code :)

[clarissedmn]

Proposition : utiliser la liste des conventional commits pour le titre des PRs également ! https://www.conventionalcommits.org/en/v1.0.0-beta.4/
Personnellement je trouve ça dommage de se cantonner à 3 préfixes PRs alors que ça apporte une précision importante pour la compréhension de la PR.

[VincentHardouin]

Je ne suis pas d'accord avec cette proposition, car ça mélange 2 choses :

• les commits qui sont à l'intention des contributeurs
• le changelog qui est à l'intention des utilisateurs

J'aime bien cet article dont l'auteur a le même avis/sentiment que moi :

Git commit messages and changelogs do not have the same target audience.

The changelog targets your users. It must answer questions like:

"What cool new feature is in this version?"
"Is this annoying bug fixed?"
"Is it safe to upgrade, or do I need to adjust my code/workflow to this new version?"

Git commit messages, on the other hand, target your project contributors. And most often contributors look at git log messages for one reason: they are trying to understand the reason for a change.

[clarissedmn]

Personnellement, je vois plus d'avantages que d'inconvénients à être explicite. De plus, étant donné qu'on utilise Semver, les utilisateurs sont informés d'un breaking change, d'une feature ou d'un bug. De mon point de vue, les PRs sont avant tout pour les contibuteurs et les préfixes apportent une communication en plus pour les reviewers notamment. :)

[VincentHardouin]

On versionne le plus souvent un groupe de PRs. Si une mise à jour majeure comprend 10 PRs comment trouver simplement celle qui contient le breaking change ?

Pour ajouter des détails à la non utilisation des types de conventional commits, on voit bien en regardant les quelques types en plus (build, ci, perf, refactor, test) sont centrés sur le code le contenu du commit et non pas sur l'impact utilisateur d'une PR.

[clarissedmn]

On peut donner l'information de breaking change également. https://www.conventionalcommits.org/en/v1.0.0/