Introduction
You join an open-source project, read a discussion on GitHub, and then... PR, LGTM, WONTFIX, RFC. You nod politely, but you have no idea what any of that means.
That’s normal. The world of development has developed its own dialect over the years, shaped by Git tools, open-source practices, and team communication habits. Here’s a glossary to help you decode it all. ✊
Git and GitHub/GitLab
Basic Actions
- Commit: a snapshot of your code at a given moment. Each commit has a message explaining what you changed and why.
-
Push / Pull:
pushsends your commits to the remote repository.pullfetches changes from the remote repository to your local machine. - Fork: a copy of a repository in your own space. You fork a project so you can contribute to it without affecting the original.
- Clone: download a local copy of a remote repository to work on it.
Branches and Merging
- Branch: a parallel development path. You create a branch to work on a feature or a fix without affecting the main branch.
- Merge: to merge changes from one branch into another. “Merging a PR” means integrating the proposed code into the main repository.
- Rebase: Reapplying your commits on top of another branch to maintain a clean, linear history.
- Conflict: When two people have modified the same lines of code differently. Git doesn’t know which one to choose, so it asks you to decide.
- Stash: Set aside changes you’re working on without committing them, so you can quickly switch branches.
Pull Requests and Issues
- PR (Pull Request) / MR (Merge Request): A proposed change. You submit your branch so it can be reviewed and integrated into the project. PR is the GitHub term; MR is the GitLab term.
- Issue: a ticket. It can be a reported bug, a requested feature, or a question. The cornerstone of open-source project management.
- Review / Code Review: the process of reviewing the code proposed in a PR before it is merged. Someone leaves comments, suggestions, or approves it.
- Draft PR: a PR marked as “in progress.” It indicates that the work isn’t finished, but that you want to share your progress.
Discussion Jargon
These terms often appear in PR and issue comments.
| Term | Meaning |
|---|---|
| LGTM | Looks Good To Me: informal approval of a PR |
| SGTM | Sounds Good To Me: same idea, for a verbal proposal |
| WIP | Work In Progress: in progress, not yet ready |
| RFC | Request For Comments: seeking feedback before making a decision |
| WONTFIX | The bug is known but will not be fixed (intentionally) |
| RTFM | Read The Friendly Manual: go read the documentation (sometimes said less politely) |
| TL;DR | Too Long; Didn't Read: summary of a long text |
| nit | Nitpick: minor comment on style or form, not a deal-breaker |
| ACK / NACK | Acknowledged / Negative Acknowledge: “I agree” / “I disagree” |
| +1 / -1 | Vote for or against a proposal |
About Projects and Contributing
- README.md: A project's welcome file. It explains what the project is, how to install it, and how to contribute.
- CONTRIBUTING.md: the project’s contribution guidelines. Read this before opening a PR.
- CHANGELOG.md: the history of changes between each version of the project.
- ROADMAP.md: the project’s roadmap, outlining what’s planned for future versions.
- AGENTS.md: supplements the README file by providing additional—and sometimes detailed—context that agents need: build steps, tests, and conventions that might clutter a README file or aren’t relevant to human contributors.
LICENSE.md / LICENCE.md: the terms of use for the code. MIT, GPL, Apache… this determines what you can do with the code.
CI/CD: Continuous Integration / Continuous Deployment. Automated pipelines that test and deploy the code with every push or merge.
upstream / downstream: “upstream” refers to the original project (the one you forked). Downstream is your version or the projects that depend on yours.
Maintainer: the person (or team) who maintains a project. They review PRs, manage issues, and make decisions.
Contributor: anyone who contributes to a project, even without direct access to the repository.
Versioning and Releases
-
SemVer (Semantic Versioning): the
MAJOR.MINOR.PATCHconvention (e.g.,2.4.1). A breaking change increments the MAJOR version. A new feature increments the MINOR version. A bug fix increments the PATCH version. -
Tag: a marker on a commit, usually to indicate a version (
v1.0.0). - Release: the official publication of a software version, often accompanied by a changelog and downloadable artifacts.
- Breaking change: a change that breaks compatibility with previous versions. This should be clearly indicated.
- Deprecation: marking a feature as obsolete before removing it in a future version.
The Right Mindset
The jargon may seem intimidating, but it’s there to speed up communication, not to exclude anyone. No one expects you to know all of this by heart right from the start.
The best way to learn: contribute. Open issues, read other people’s PRs, ask questions. Most open-source communities are welcoming to beginners, especially if you’ve read CONTRIBUTING.md and README.md beforehand. 😄
Learn More
- Git - A Short Guide: The basics of Git in French
- First Contributions: a step-by-step guide to your first pull request
- Choose a License: understanding open-source licenses
- Semantic Versioning: Understanding semantic versioning
-
Agents.md: A guide to writing a clear and useful
AGENTS.mdfile
Find me on GitHub or Discord to chat about development and open source!
Top comments (1)
This is a really valuable topic because development and open source culture are heavily shaped by acronyms and jargon, often to the point where they become a barrier for newcomers.
What stands out is how quickly terms like CI/CD, PR, RFC, SDK, or MVP become “assumed knowledge,” even though each one represents a fairly complex concept. Over time, this creates an implicit divide between experienced contributors and new developers who are still decoding the language.
The interesting tension is that jargon improves efficiency within a team, but reduces accessibility across communities. Open source especially suffers from this because documentation and discussions often prioritize speed over clarity.
I like the implicit reminder here: good engineering communication isn’t just about being correct, it’s about being understandable outside your immediate context. That’s often what determines whether a project is truly open or just publicly visible.
A small but important piece of culture that has a big impact on onboarding and collaboration.