Release & Governance Reality

This section takes you inside the maintainer and Technical Steering Committee (TSC) view of OpenSearch. The Contributor Mindset section answered the question "how do I behave so my work gets accepted?" This section answers the opposite, asymmetric question: what is the work being done by the people who accept your pull request? — what a maintainer reads in your diff, why a "trivial" change gets heavy scrutiny, how a fix actually ships in a release, and who decides any of it.

It is written for two audiences:

1. Contributors who want to understand maintainers. If you know what a maintainer is worried about — backward compatibility across a mixed cluster, the blast radius of a change, the cost of a revert — you write PRs that get merged instead of stalling.
2. Aspiring maintainers. The path from contributor to maintainer to TSC is not a mystery, but nobody hands you the operational playbook. This section is that playbook.

The chapters are deliberately not aspirational. They are the mechanics — which CI check gates a merge, what the backport 2.x label does, where the SPDX header and licenses/ rules are bright lines, and what a "release readiness" issue tracks.

Note: OpenSearch is not an Apache project, and its governance is not the Apache model. There is no PMC, no IPMC, no incubator, no [VOTE] email thread, and no JIRA. If you came here from an Apache background (or from the sibling Apache Tez curriculum), unlearn those reflexes. The differences are spelled out below and recur throughout the section.

How OpenSearch Governance Differs From the Apache Model

The Apache Software Foundation governs each project through a Project Management Committee (PMC) that holds binding votes, cuts releases by a formal [VOTE] email on a developer mailing list, and tracks work in JIRA. OpenSearch works nothing like that.

The single most important reframing: in OpenSearch, the design discussion, the review, the merge decision, the backport, and the release tracking all happen in public on GitHub. There is no private mailing list where the "real" decision is made. The artifact you watch is an issue thread and a PR, not an email vote. If you can read GitHub, you can read the governance.

Reading Order

The section is one index plus seven chapters. Read them in order the first time; afterwards they stand alone.

Chapters 1–2 and 6–7 are immediately useful to any contributor. Chapters 3–5 are maintainer- and release-facing, but read them early: understanding why a maintainer blocks a "small" change on compatibility grounds, or why the backport deadline is firm, will save you a stalled PR.

How This Differs From the Contributor Mindset Section

The two sections are halves of the same coin and are meant to be read together:

• The Contributor Mindset section is first person: reading the codebase, designing via GitHub, writing a high-quality PR, responding to feedback, thinking about compatibility, and aiming for maintainership. It is what you do.
• This section is second person, inverted: it is what the maintainer reviewing you, the release manager shipping you, and the TSC governing the project do. It is the other side of the table.

Specifically, several mindset chapters have a governance mirror here:

Read your own behavior in the mindset section, then read what the receiving end expects here, and your PRs converge on what gets merged.

Prerequisites

Before this section is fully useful:

• You have read the Contributor Mindset section, especially compatibility.md and pr-quality.md.

• You have a GitHub account and have configured DCO sign-off (git config commit.gpgsign is optional; the Signed-off-by: trailer from git commit -s is mandatory).

• You have a local clone of the core engine at ~/OpenSearch:

  git clone https://github.com/opensearch-project/OpenSearch.git ~/OpenSearch
  cd ~/OpenSearch
  ls CONTRIBUTING.md DEVELOPER_GUIDE.md MAINTAINERS.md CHANGELOG.md TESTING.md
  

• You have skimmed CONTRIBUTING.md, DEVELOPER_GUIDE.md, and MAINTAINERS.md in that clone. These are the authoritative process documents; this section explains the why behind them, not a substitute for them.

• You have an account on forum.opensearch.org and have joined the public Slack at opensearch.org/slack (covered in Communication Channels).

If you intend to follow the capstone, you will exercise nearly everything in this section: getting a real PR reviewed (github-review.md), backported, and into a release (release-process.md).

You've Absorbed This Section When…

You have internalised this material when you can, without looking it up:

1. Name the CI checks that gate a merge on the core repo (gradle-check, assemble, precommit, DCO) and say what each one protects.
2. Explain why OpenSearch uses review-then-merge with maintainer approval, not commit-then-review.
3. Add the backport 2.x label to a merged PR and describe exactly what the backport bot then does — and what to do when it conflicts.
4. Predict, before opening an issue, whether it belongs as a plain bug, an enhancement, or an RFC/proposal, and which channel drives consensus for each.
5. Read a diff that touches StreamInput/StreamOutput or a REST response shape and predict whether a maintainer will block it on backward-compatibility grounds. (See the serialization-BWC deep dive.)
6. Trace how a one-line fix merged to main ends up in a 2.x patch release: the CHANGELOG.md entry, the backport, the release-readiness issue, the release manager, and the generated release notes.
7. Add a new dependency and correctly predict the license review it triggers: SPDX header, the licenses/ SHA + LICENSE/NOTICE files, and the allowed-license check.
8. Describe the contributor → maintainer → TSC ladder and what changes at each rung.

The next chapter — Communication Channels and Building Consensus — covers the operational mechanics of the GitHub/forum/Slack/community-meeting system that this entire section relies on.