Acronyms and Jargon in Development and Open Source

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: push sends your commits to the remote repository. pull fetches 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.

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.PATCH convention (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.md file

Find me on GitHub or Discord to chat about development and open source!