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.

In Practice: Navigating Nuance – A Developer’s Perspective

The core concepts outlined in “English for Open Source Governance”—BDFLs, CLAs, RFCs—are fantastic building blocks. But translating that understanding into actual communication as a developer can be tricky, especially when you’re still refining your professional English. It’s not just about knowing the definitions; it’s about conveying your ideas clearly and respectfully within the collaborative environment of an open-source project. Let’s look at some scenarios where those vocabulary terms truly come to life, and how a non-native speaker can approach them with confidence.

Consider this: you’ve submitted a pull request (PR) containing a significant refactoring of a module. During code review, another developer leaves a comment that reads, “This is a good start, but the logic here feels… lazy. Can you elaborate on your reasoning behind bypassing the existing validation checks?” Now, understanding that “lazy consensus” refers to a lack of robust justification for decisions can be helpful, but how do you respond effectively? A direct translation might sound awkward. Instead, try something like: “I appreciate the feedback. My intention was to streamline this process for performance reasons, and I’ve documented the rationale in the commit message outlining the changes. However, I recognize that a more formal RFC might be beneficial to thoroughly discuss the potential implications of bypassing these checks – perhaps we could schedule a brief discussion on this?” Notice how framing it as an invitation to further conversation rather than a defensive statement makes a huge difference. Similarly, when drafting your own PR descriptions, avoid overly technical jargon if possible and focus on the impact of your changes. “Fixes a bug” is fine, but “Addresses a memory leak in the data processing pipeline due to inefficient string concatenation” might be overwhelming for reviewers who aren’t intimately familiar with the code.

Another situation arises during Slack conversations about proposing new features. Perhaps a discussion emerges around whether or not to adopt a particular approach – let’s say regarding how to handle user authentication. Someone suggests, “Let’s just go with OAuth2; it’s the standard.” You might instinctively push back, “But doesn’t that introduce significant security concerns if we don’t implement X and Y properly?” Understanding that advocating for an RFC (Request For Comments) is a valid process to formally explore these concerns – rather than simply dismissing the suggestion – demonstrates your engagement with project governance. It shows you’re thinking critically about potential risks and contributing constructively to the decision-making process.

Finally, remember that even seemingly small phrases can have significant implications. Using active voice (“I believe…”) is generally preferred over passive voice (“It should be considered…”). And consistently referring to established processes like “the DCO (Derived Copyright Owner) guidelines” or “the CLA (Contributor License Agreement)” demonstrates you’re familiar with the project’s legal framework and committed to following its rules.

# Example: Using git to check for a CLA file associated with a repository
git ls-tree -r --name-only HEAD | grep CLA

This command, while simple, illustrates how technical vocabulary connects directly to practical workflows within an open-source project – verifying compliance and understanding the legal aspects of contributing. Mastering this blend of technical terminology and clear communication is key to becoming a valued member of any open-source community.