Rédiger des pull requests

Standards pour les titres et descriptions de PR dans tldraw/tldraw.

Titre de la PR

Utilisez des titres de PR sémantiques (format Conventional Commits) :

<type>(<scope>): <description>

Types

feat - Nouvelle fonctionnalité
fix - Correction de bug
docs - Documentation uniquement
refactor - Changement de code qui ne corrige ni bug ni n'ajoute de fonctionnalité
perf - Amélioration de performance
test - Ajout ou correction de tests
chore - Tâches de maintenance

Scope (optionnel)

Un nom décrivant la zone affectée : fix(editor):, feat(sync):, docs(examples):

Exemples

feat(editor): add snap threshold configuration option
fix(arrows): correct binding behavior with rotated shapes
docs: update sync documentation
refactor(store): simplify migration system

Corps de la PR

Utilisez ce template :

<description paragraph>

### Change type

- [x] `bugfix` | `improvement` | `feature` | `api` | `other`

### Test plan

1. Step to test...
2. Another step...

- [ ] Unit tests
- [ ] End to end tests

### Release notes

- Brief description of changes for users

Paragraphe de description

Commencez par : « Pour X, cette PR fait Y. »

Restez spécifique - évitez les phrases vagues comme « améliorer l'expérience utilisateur »
Liez les issues connexes dans le premier paragraphe
Ne supposez pas que les lecteurs liront aussi l'issue liée

Change type

Cochez exactement un type avec [x]
Supprimez les éléments non cochés

Test plan

Listez les étapes de test manuel si applicable
Supprimez la liste numérotée si les changements ne peuvent pas être testés manuellement
Cochez les cases pour les types de tests inclus

Release notes

Écrivez de brèves notes décrivant les changements visibles pour les utilisateurs
Utilisez l'impératif : « Ajouter... », « Corriger... », « Supprimer... »
Omettez entièrement cette section pour le travail interne (CI, outillage, tests, etc.) sans impact utilisateur

Concepts, exemples et FAQ (pour les PRs volumineuses ou riches en fonctionnalités)

Quand une PR introduit un nouveau système, plusieurs nouveaux types/APIs, ou a autrement assez de surface qu'un reviewer bénéficierait d'un glossaire, incluez des sections explicatives supplémentaires au-dessus du bloc standard ### Change type / ### Test plan / ### Release notes. Ignorez ces sections pour les PRs petites ou ciblées — elles sont destinées aux fonctionnalités et grands refactors.

Puisez dans ce menu, à peu près dans cet ordre, en utilisant seulement ce qui s'adapte :

Concepts — un tableau des nouveaux termes/types que la PR introduit, avec les colonnes Term | Type | Meaning. Utilisez ceci quand les lecteurs ont besoin d'un vocabulaire partagé pour suivre le reste de la description.
Module augmentation — de courts blocs de code montrant comment les consommateurs étendent les nouveaux types, quand la PR expose des interfaces augmentables.
Editor API / Component props — tableaux Method | Description et Prop | Type | Description pour la nouvelle surface publique.
Per-shape / per-feature breakdown — tableaux montrant ce que chaque shape/module affecté retourne ou accepte sous le nouveau système.
Example — un snippet de code réaliste, copiable, montrant comment une implémentation par défaut utilise le nouveau système, plus un deuxième snippet montrant comment un consumer l'overriderait.
FAQ — questions anticipées « Comment puis-je...? » avec de courtes réponses en code. Couvrez les chemins de customisation évidents qu'un utilisateur downstream atteindra en premier.
New examples — liste à puces de toute entrée nouvelle ajoutée sous apps/examples/src/examples/, avec une description d'une ligne chacune, afin que les reviewers sachent où chercher les démos exécutables.

Référence : tldraw/tldraw#8410 est un bon exemple travaillé de toutes ces sections ensemble.

Ces sections viennent avant ### Change type. Les blocs standard ### Change type / ### Test plan / ### Release notes / ### API changes / ### Code changes apparaissent toujours au bas dans l'ordre usuel.

Section API changes

À inclure quand des changements affectent api-report.md :

### API changes

- Added `Editor.newMethod()` for X
- Breaking! Removed `Editor.oldMethod()`
- Changed `Editor.method()` to accept optional `options` parameter

Tableau des changements de code

Créez un tableau qui inclut les changements de LOC net pour chacune des sections suivantes. La somme de toutes les lignes doit correspondre au diff total de la PR. Omettez les lignes sans changements.

Core code — packages SDK (packages/) source, excluant les tests et rapports API
Tests — unit tests, e2e tests (*.test.*, e2e/)
Automated files — fichiers générés (p. ex. api-report.api.md, snapshots)
Documentation — site de docs et exemples (apps/docs/, apps/examples/)
Apps — code applicatif (apps/dotcom/, apps/mcp-app/, apps/vscode/, etc.), excluant les e2e tests
Templates — starter templates (templates/)
Config/tooling — fichiers config, lock files, lint config, CI, build scripts (eslint.config.*, yarn.lock, etc.)

### Code changes

| Section         | LOC change |
| --------------- | ---------- |
| Core code       | +10 / -2   |
| Tests           | +5 / -0    |
| Automated files | +0 / -1    |
| Documentation   | +2 / -0    |
| Apps            | +3 / -1    |
| Templates       | +0 / -0    |
| Config/tooling  | +1 / -0    |

Issues connexes

Cherchez et liez les issues pertinentes que cette PR adresse.

Notes humaines (préserver exactement)

L'auteur de la PR écrit souvent une note personnelle tout en haut de la description, précédée d'un emoji « personne » comme 🅯 ou 👨 (ou similaire). Ce bloc est écrit par un humain et les lecteurs le font confiance comme tel.

Quand vous mettez à jour une description de PR existante, si le corps commence par un paragraphe/section conduit par un emoji personne, vous DEVEZ le préserver byte-for-byte exactement au top — ne le réécrire, refondre, reformuler, retitrer, ou « améliorer » même légèrement.
Si la note humaine est plus longue qu'un seul paragraphe, elle sera délimitée à la fin par une règle horizontale ---. Préservez tout depuis l'emoji personne jusqu'à (et incluant) ce --- exactement.
S'il n'y a pas de ---, la note humaine est juste le paragraphe initial conduit par l'emoji personne.
Faites tous vos édits au contenu en dessous de la note humaine (et en dessous du --- si présent).
Quand vous créez une nouvelle PR, n'inventez pas une note humaine — laissez ça à l'auteur pour l'ajouter.

Important

N'incluez jamais d'attribution IA à moins que la PR ne se rapporte directement à l'outillage IA
N'utilisez jamais la casse de titre pour les descriptions - utilisez la casse de phrase
Ne vous mettez jamais comme co-auteur d'aucun commit
Incluez toujours une section API changes si la PR a des changements à n'importe quel api-report.md

write-pr