Communication Channels and Building Consensus

OpenSearch has no private decision-making channel. There is no dev@ list where the "real" discussion happens, no JIRA, no committee email thread you need to be cc'd on. The project's nervous system is a small set of public channels, and consensus is something you can watch being built in the open. This chapter is the operational map: which channel does what, when to use which, and how to drive a proposal from idea to merged change without burning goodwill.

If you have read Design via GitHub from the contributor side, this is the maintainer- and process-side view of the same machinery.

The Channels at a Glance

There is exactly one bright line to memorize: a decision is not real until it is written down in a GitHub issue or PR. Slack threads and hallway conversations at a community meeting are where alignment forms; the issue is where it is recorded. If you negotiate a design in Slack, your last act is to post the summary back on the issue. Maintainers will ask you to do this if you don't.

Warning: Never treat a Slack +1 or a verbal nod in a community meeting as approval to merge. The approval that counts is a maintainer's review on the PR. Anything else is just momentum.

What Each Channel Is For — and Not For

GitHub Issues

The issue is the unit of work. Every bug, every feature, every design lives here first. Issues carry labels that route and stage them:

A maintainer triaging an issue moves it from untriaged to a real category, may ask for a reproduction, and may attach it to a release version. You can accelerate this: a clean, reproducible bug report with a curl repro against localhost:9200 and the exact version gets triaged faster than a vague one. See GitHub Issues and PR Review for the triage-to-merge flow.

The Forum (forum.opensearch.org)

The forum is for discussion that isn't yet a unit of work: "Is this expected behavior?", "How do others solve X?", "We're thinking about a feature in this area — has anyone tried?" It is durable and searchable, which makes it better than Slack for anything you want to reference later. If a forum thread converges on "this is a bug" or "this is worth building," the outcome is to open a GitHub issue and link the thread.

Slack (opensearch.org/slack)

Slack is for speed and for humans: unblocking a quick question, finding which maintainer owns an area, coordinating who takes which piece, sanity-checking before you write a long issue. It is ephemeral — old messages scroll away and aren't a record. Use it to move fast, then write the outcome down.

Community Meetings

Recorded, public, recurring meetings cover TSC updates, roadmap, project demos, and open discussion. As a contributor you mostly consume these (watch a recording to understand direction). As an aspiring maintainer you eventually present in them — demoing a feature or walking an RFC. Because they are recorded and minuted, they are a legitimate way to surface a proposal to a wide audience, but the binding artifact is still the linked issue.

How Consensus Is Actually Built

OpenSearch consensus is lazy consensus plus maintainer approval, scaled by blast radius. The bigger the change, the wider the circle that must align.

flowchart TD
    A[Idea / problem] --> B{Scope?}
    B -->|Bug or small change| C[Open issue: bug/enhancement]
    B -->|New feature / design| D[Open RFC issue: label RFC/proposal]
    B -->|Cross-cutting / multi-repo| E[RFC + community meeting + TSC]
    C --> F[Discussion on the issue]
    D --> F
    E --> F
    F --> G{Maintainer alignment?}
    G -->|No objection / +1s| H[Open PR implementing it]
    G -->|Objection| I[Iterate on issue: revise scope/design]
    I --> F
    H --> J[Review-then-merge: maintainer approvals + green CI]
    J --> K[Merged + CHANGELOG entry]
    K --> L{Needs older line?}
    L -->|Yes| M[backport label -> bot opens backport PR]
    L -->|No| N[Ships in next release of main]

The three circles, by blast radius:

1. Discussion on the issue / RFC. For a contained change, this is the whole game. You describe the problem, a maintainer agrees on the approach, you implement it. "Lazy consensus" means silence after a clear proposal, given reasonable time, is assent — but only a maintainer's actual review approves the PR.
2. Maintainer alignment. For anything touching a public surface — REST API, wire format, index format, a setting's default — the maintainers who own that area must agree before you write much code. Getting this alignment on the issue is the single highest-leverage thing you can do; it is far cheaper to change a paragraph than a 2,000-line PR. See How Maintainers Think About Compatibility for what they weigh.
3. The TSC for cross-cutting concerns. Changes that span repos, set project-wide policy, add a whole subsystem, or affect the experience across the bundle escalate to the Technical Steering Committee. You usually don't go straight to the TSC; a maintainer or the discussion routes it there when it's warranted.

When to Use Which Channel

Warning: Security vulnerabilities are the one thing that does not go in a public channel. Follow the coordinated disclosure process documented in SECURITY.md (a private report path), never a public issue, forum post, or Slack message.

Driving a Proposal — The Playbook

To take an idea to a merged change without stalling:

1. Search first. Check existing issues, the forum, and MAINTAINERS.md. Half of all "new" proposals already have a thread; join it instead of forking the discussion.
2. Write the problem, not the solution, first. A good RFC issue leads with the problem, the constraints, and why now, then proposes an approach and lists alternatives you rejected. Maintainers evaluate problems; they distrust solutions that arrive without one.
3. Label it correctly. RFC/proposal for design, enhancement for a concrete change, meta for a multi-PR tracking effort. Mislabeling buries your issue.
4. Tag the right owners. Use MAINTAINERS.md to find who owns the area and @-mention them — but tag, don't spam. One thoughtful ping beats five.
5. Get alignment before you build. Do not open a large PR before the design has a maintainer's blessing on the issue. A PR is a commitment; an issue is a conversation. Pay for the conversation first.
6. Implement in a focused PR that links the issue (Closes #NNNN), adds a CHANGELOG.md entry, and is small enough to review. See GitHub Issues and PR Review.
7. Summarize decisions back onto the issue. If alignment happened in Slack or a meeting, post the conclusion on the issue so the record is complete.

Etiquette

The norms that make you easy to work with — and that maintainers remember:

• Be concise and reproducible. A maintainer's scarcest resource is attention. A three-line repro saves them twenty minutes and earns you review bandwidth.
• Don't cross-post the same question to three channels. Pick the right one; escalate only if it goes stale, and link the prior thread when you do.
• Assume good faith and respond to the strongest version of the objection. Maintainers block changes for reasons (usually compatibility or maintenance cost), not to gatekeep.
• Follow the Code of Conduct. It is not decorative.
• Be patient and persistent, not loud. Reviewers are volunteers and employees with finite time. A polite "friendly ping" after several days is fine; daily nagging is not.
• Leave the channel better than you found it. Update the issue when you learn something; close your own stale threads; link duplicates.

These manners are not soft skills — they are how you accumulate the trust that turns into review bandwidth and eventually maintainership.

Prove You Understand This

1. Where is the authoritative record of a design decision, and where is it merely formed?
2. You discussed and agreed an approach with a maintainer in Slack. What is your last step before writing code?
3. You believe you found a remotely exploitable bug. Which channel do you use, and which do you explicitly avoid?
4. A new feature you want spans the core repo and two plugin repos. Sketch the path from idea to merged change, naming the channels and the point at which the TSC gets involved.
5. What does the untriaged label mean, and what would make a maintainer remove it from your issue quickly?

The next chapter — GitHub Issues and PR Review — turns from forming consensus to executing it: how a PR actually gets reviewed and merged.