Les acronymes et le jargon dans le dev et l'open source

Introduction

Tu rejoins un projet open source, tu lis une discussion sur GitHub, et là… PR, LGTM, WONTFIX, RFC. Tu hoches la tête poliment, mais tu n’as aucune idée de ce dont il s’agit. C’est normal. Le monde du dev a développé son propre dialecte au fil des années, entre les outils Git, les pratiques open source et les habitudes de communication des équipes. Voici un lexique pour décoder tout ça. ✊

Autour de Git et GitHub/GitLab

Les actions de base

Commit : un instantané de ton code à un moment donné. Chaque commit a un message qui explique ce que tu as changé et pourquoi.
Push / Pull : push envoie tes commits vers le dépôt distant. pull récupère les changements depuis le dépôt distant vers ta machine locale.
Fork : une copie d’un dépôt dans ton propre espace. Tu forkes un projet pour pouvoir y contribuer sans toucher à l’original.
Clone : télécharger une copie locale d’un dépôt distant pour travailler dessus.

Les branches et la fusion

Branch / Branche : une ligne de développement parallèle. On crée une branche pour travailler sur une fonctionnalité ou un correctif sans affecter la branche principale.
Merge : fusionner les changements d’une branche dans une autre. “Merger une PR” c’est intégrer le code proposé dans la base principale.
Rebase : réappliquer ses commits par-dessus une autre branche, pour garder un historique propre et linéaire.
Conflict / Conflit : quand deux personnes ont modifié les mêmes lignes de code différemment. Git ne sait pas lequel choisir, il te demande de trancher.
Stash : mettre de côté des changements en cours sans les committer, pour switcher de branche rapidement.

Les Pull Requests et Issues

PR (Pull Request) / MR (Merge Request) : une proposition de changement. Tu soumets ta branche pour qu’elle soit relue et intégrée dans le projet. PR c’est le terme GitHub, MR c’est GitLab.
Issue : un ticket. Ça peut être un bug signalé, une fonctionnalité demandée, ou une question. La pierre angulaire de la gestion de projet open source.
Review / Code Review : la relecture du code proposé dans une PR, avant qu’il soit mergé. Quelqu’un laisse des commentaires, des suggestions, ou valide.
Draft PR : une PR marquée “en cours”. Elle signale que le travail n’est pas terminé, mais que tu veux partager ton avancement.

Le jargon des discussions

Ces termes apparaissent souvent dans les commentaires de PR et d’issues.

Terme	Signification
LGTM	Looks Good To Me : approbation informelle d’une PR
SGTM	Sounds Good To Me : même idée, pour une proposition verbale
WIP	Work In Progress : en cours, pas encore prêt
RFC	Request For Comments : on demande des avis avant de décider
WONTFIX	Le bug est connu mais ne sera pas corrigé (volontairement)
RTFM	Read The Friendly Manual : va lire la doc (parfois dit avec moins d’amabilité)
TL;DR	Too Long; Didn’t Read : résumé d’un texte long
nit	Nitpick : remarque mineure sur du style ou de la forme, pas bloquante
ACK / NACK	Acknowledged / Negative Acknowledge : “j’approuve” / “je m’oppose”
+1 / -1	Vote pour ou contre une proposition

Autour des projets et de la contribution

README.md : le fichier d’accueil d’un projet. Il explique ce que c’est, comment l’installer, comment contribuer.
CONTRIBUTING.md : les règles de contribution du projet. Lis-le avant d’ouvrir une PR.
CHANGELOG.md : l’historique des changements entre chaque version du projet.
ROADMAP.md : la feuille de route du projet, ce qui est prévu pour les prochaines versions.
AGENTS.md : complète le fichier README en fournissant le contexte supplémentaire, parfois détaillé, dont les agents ont besoin : étapes de compilation, tests et conventions qui risqueraient d’encombrer un fichier README ou qui ne sont pas pertinents pour les contributeurs humains.
LICENSE.md / LICENCE.md : les droits d’utilisation du code. MIT, GPL, Apache… ça détermine ce que tu peux faire avec.
CI/CD : Continuous Integration / Continuous Deployment. Des pipelines automatisés qui testent et déploient le code à chaque push ou merge.
upstream / downstream : l’upstream c’est le projet original (celui que tu as forké). Le downstream c’est ta version ou les projets qui dépendent du tien.
Maintainer : la personne (ou l’équipe) qui maintient un projet. Elle relit les PR, gère les issues, prend les décisions.
Contributor : toute personne qui contribue à un projet, même sans accès direct au dépôt.

Le versioning et les releases

SemVer (Semantic Versioning) : la convention MAJOR.MINOR.PATCH (ex: 2.4.1). Un breaking change fait monter le MAJOR. Une nouvelle fonctionnalité le MINOR. Un correctif le PATCH.
Tag : un marqueur sur un commit, généralement pour indiquer une version (v1.0.0).
Release : la publication officielle d’une version d’un logiciel, souvent accompagnée d’un changelog et d’artefacts téléchargeables.
Breaking change : un changement qui casse la compatibilité avec les versions précédentes. À signaler clairement.
Deprecation : marquer une fonctionnalité comme obsolète, avant de la supprimer dans une future version.

Le bon état d’esprit

Le jargon peut sembler intimidant, mais il est là pour accélérer la communication, pas pour exclure. Personne ne s’attend à ce que tu connaisses tout ça par cœur dès le début. La meilleure façon d’apprendre : contribue. Ouvre des issues, lis les PR des autres, pose des questions. La plupart des communautés open source sont bienveillantes envers les débutants, surtout quand on a lu le CONTRIBUTING.md et le README.md avant. 😄

Pour aller plus loin

git - petit guide : le b.a.-ba de Git en français
First Contributions : ta première PR guidée pas à pas
Choose a License : comprendre les licenses open source
Semantic Versioning : comprendre le versioning sémantique
Agents.md : un guide pour rédiger un fichier AGENTS.md clair et utile

Retrouve-moi sur GitHub ou Discord pour échanger sur le dev et l’open source !