English for Open Source Governance

Contributing to a large open source project means navigating not just code, but governance. Every mature project has its own structure for making decisions, resolving conflicts, and defining who has authority. If you do not understand the vocabulary of open source governance, you may struggle to participate effectively in discussions, contribute at the right level, or understand why your pull request was closed. This post covers the essential terms.

Key Vocabulary

BDFL — Benevolent Dictator For Life. A single person who holds ultimate decision-making authority over a project. The term was coined for Guido van Rossum in the Python community. Example: “The BDFL made the final call on the new type annotation syntax.”

Steering committee — A group of elected or appointed leaders who make high-level decisions for a project. Example: “The proposal needs to be approved by the steering committee before implementation begins.”

Contributor Covenant (CoC) — The Contributor Covenant is the most widely adopted Code of Conduct for open source communities. It defines acceptable behaviour and the process for reporting violations. Example: “All contributors are expected to follow the Contributor Covenant.”

DCO vs CLA — A DCO (Developer Certificate of Origin) is a lightweight sign-off confirming that you wrote the code and have the right to contribute it, added with git commit -s. A CLA (Contributor Licence Agreement) is a more formal legal agreement, often required by corporate-backed projects. Example: “This project uses a DCO instead of a CLA to reduce friction for new contributors.”

RFC (Request for Comments) — A formal document proposing a significant change or new feature. The RFC process invites community feedback before a decision is made. Example: “We opened an RFC for the new plugin API three weeks ago and have been collecting feedback.”

Lazy consensus — A decision-making model where a proposal passes if nobody objects within a set time period. Silence is treated as agreement. Example: “The change was approved by lazy consensus after a 72-hour review window.”

Technical governance — The policies and processes that define how technical decisions are made in a project. Example: “The GOVERNANCE.md file explains our technical governance model.”

GOVERNANCE.md — A file in a repository’s root directory that documents the project’s governance structure, decision-making processes, and roles. Example: “Before submitting your proposal, read GOVERNANCE.md to understand the RFC process.”

SIG (Special Interest Group) — A focused working group within a larger project that owns a specific domain. Common in projects like Kubernetes. Example: “The SIG for networking owns decisions about CNI plugins.”

Triaging issues — The process of reviewing new issues to assign labels, priority, reproduce bugs, and decide whether they are valid. Example: “We triage incoming issues every Monday morning to keep the backlog manageable.”

How to Use This in Practice

When you join an open source project, the first step is reading the GOVERNANCE.md and CONTRIBUTING.md files. These tell you how decisions are made and what is expected of contributors.

If you want to propose a significant change, check whether the project uses an RFC process. Projects like Rust, Ember, and React all have RFC repositories. You open a pull request with a structured document, the community comments, and eventually a decision is made by the steering committee or BDFL.

For everyday contributions, understand that lazy consensus is common for smaller decisions: if you open a PR, add a comment explaining your intent, and nobody objects after a week, it may be merged without formal approval.

If a project requires a DCO, you can sign off commits with git commit -s -m "Your message". This adds a Signed-off-by: line to the commit. A CLA is a separate legal document you usually sign through a web form.

Example Conversation

Priya: “I want to propose a new query syntax for the project. Should I just open a PR?”

Maintainer: “For something this significant, we’d prefer an RFC. Check GOVERNANCE.md for the template. Once you submit it, it goes through a 30-day comment period before the steering committee votes.”

Priya: “Got it. Does my company need to sign a CLA?”

Maintainer: “We use a DCO instead — just make sure to sign off your commits with git commit -s.”

Practice Tips

1. Read a real GOVERNANCE.md: Look at the governance files for Kubernetes (kubernetes/community) or the Rust project (rust-lang/rfcs). List five governance terms you find there and write a one-sentence definition of each in your own words.

2. Follow an RFC discussion: Find an open RFC in a project you use (React, Vue, Rust, or Python’s PEPs are good choices). Read through the comments and identify the language people use to agree (“this LGTM”), object (“I’m concerned about…”), or request changes (“could we consider an alternative where…”).

3. Practise the triage vocabulary: Next time you read an issue tracker, try labelling each issue mentally: “This needs triage,” “This is a duplicate,” “This is out of scope,” “This is ready for a contributor.” Using the vocabulary actively — even silently — builds fluency.