doc / adoption
Adoption : assist → warn → enforce
La manière la plus sûre d'introduire une convention dans une équipe consiste à avancer progressivement : aider d'abord, rendre les points à traiter visibles ensuite, puis décider ensemble s'il faut aller jusqu'à rendre son respect obligatoire. Assist et warn fonctionnent dès aujourd'hui uniquement via l'extension. Enforce, dans sa dimension de contrôle de fusion au niveau de la plateforme, reste sur la feuille de route — consultez la feuille de route pour en savoir plus.
Les étapes d'adoption
| Mode | Ce que fait l'extension | Effet sur la pull request |
|---|---|---|
| off | Ne fait rien. | Aucun. |
| assist | Aide les relecteurs à rédiger des commentaires conformes et signale les problèmes détectés. Ne bloque jamais. | Aucun. |
| warn | Comme assist, avec en plus un décompte visible des fils bloquants non résolus. | Les points restent visibles, sans bloquer. |
| enforce | Peut refuser localement, dans le navigateur, l'envoi d'un commentaire mal formé. | Aucun contrôle de fusion au niveau de la plateforme n'est encore disponible. |
Comme ces étapes reposent aujourd'hui uniquement sur l'extension, passer de l'une à l'autre revient à modifier la configuration. Il n'y a aucun service séparé à déployer, redémarrer ou retirer.
Un prérequis à anticiper
Configurez resolverOverrideGroup avant de compter sur les réponses decision pour résoudre un fil bloquant. Ce paramètre définit qui peut enregistrer une decision lorsque l'auteur du commentaire bloquant n'est pas disponible. S'il reste vide, personne ne peut utiliser ce mécanisme de secours et un fil bloquant peut rester sans personne autorisée pour le résoudre.
Revenir en arrière
Chaque étape correspond à une valeur du paramètre mode, appliquée via le même système à trois niveaux décrit dans la configuration. Repasser de warn à assist, ou du mode strict local d'enforce à warn, prend effet dès la prochaine lecture de la configuration par l'extension. Aucun service n'est à redémarrer et aucune règle de protection de branche n'est à modifier, puisque ces modes n'agissent pas encore sur les règles de fusion de la plateforme.
Ce qu'il faut surveiller avant d'aller plus loin
Il n'existe pas encore de tableau de bord à l'échelle de l'organisation. Une vue agrégée de ce type deviendra pertinente avec un futur contrôle exécuté au niveau de la plateforme. En attendant, l'observation reste surtout qualitative : les relecteurs trouvent-ils les bons labels ? Les fils bloquants sont-ils réellement résolus ? Le décompte affiché en warn revient-il généralement à zéro avant la fusion ? Un usage très inégal des labels ou des points bloquants qui restent systématiquement ouverts sont de bonnes raisons de ne pas durcir les règles trop vite.
Configuration à chaque étape
Un seul paramètre doit changer en passant d'une étape à l'autre : mode. Tout le reste devrait déjà être en place.
{ "version": 1, "mode": "warn", // assist → warn → enforce "resolverOverrideGroup": ["acme/tech-leads"], "formatSeverity": "warn", // les erreurs de format ne bloquent pas "exemptUsers": ["dependabot[bot]", "github-actions[bot]"], "toolCommands": ["/*", "@dependabot", "@renovate"] }
toolCommands est vide par défaut. Dans le mode strict local d'enforce, un /rebase utilisé seul est rejeté comme n'importe quel autre commentaire non conforme, sauf s'il a été déclaré. Ajouter "/*" exempte toutes les commandes commençant par /.