OpenSearch Contributor Mindset

This section is the "soft skills with hard edges" half of the curriculum. The Levels teach you the mechanics — how to build OpenSearch from source, trace a search request, write a query builder, fix an allocation decider. This section teaches you the behavior and judgment that turns a working diff into a merged pull request and, eventually, into maintainer trust.

These are not optional skills. A technically excellent PR with poor process around it sits in the queue for months and is quietly closed as stale. A modest, focused PR with clean process — DCO sign-off, a CHANGELOG entry, green CI, a tight description tied to an issue — gets a maintainer's attention and gets merged. The difference is rarely the code.

OpenSearch is a GitHub-native project under the OpenSearch Software Foundation (Linux Foundation). That single fact reshapes everything in this section relative to a classic Apache project: design lives in GitHub issues and PR threads, not JIRA; contributions require a DCO sign-off (git commit -s), not a CLA; iteration happens by force-pushing the PR branch, not by re-rolling numbered patch files; and trust is recorded in a per-repo MAINTAINERS.md, governed by a Technical Steering Committee (TSC).

Reading Order

The seven chapters are ordered to mirror the actual arc of a new contributor: learn to read, learn where decisions live, learn to talk, learn to ship, learn to iterate, learn what you may break, learn how trust accrues.

Chapters 1–2 are pre-work — read them before opening any issue. Chapters 3–5 are operational — read them before submitting your first PR. Chapters 6–7 are strategic — read them when you start thinking beyond a single change.

How This Section Differs From the Levels

The distinction is deliberate and worth internalizing:

The Levels make you able to do the work. This section makes the work land. A maintainer evaluating you is not grading your understanding of InternalEngine; they are grading whether your PR is safe, scoped, tested, and respectful of their time. That is judgment, and judgment is what this section trains.

How This Section Complements the Rest of the Book

The relationship is concrete. Each mindset chapter pairs with technical material:

If you are doing the Capstone, you should have read all seven chapters by the time you reach the step where you open your real PR. The Capstone is graded in part on process — the things this section teaches.

What This Section Is Not

It is not generic open-source advice. Every claim, template, and procedure here is grounded in OpenSearch-specific reality:

• The GitHub repo opensearch-project/OpenSearch, its issues, and its PR threads.
• The in-repo policy files: CONTRIBUTING.md, DEVELOPER_GUIDE.md, TESTING.md, CHANGELOG.md, MAINTAINERS.md, .github/pull_request_template.md, CODE_OF_CONDUCT.md.
• The community forum at forum.opensearch.org, the public Slack at opensearch.org/slack, and recorded community meetings.
• The TSC's published governance under the OpenSearch Software Foundation / Linux Foundation.

Where a chapter generalizes, it labels the generalization. Where it states an OpenSearch-specific rule, it cites the in-repo file or the GitHub mechanism that enforces it.

Prerequisites

Before this section is useful you must have:

• A local clone of OpenSearch:

  git clone https://github.com/opensearch-project/OpenSearch.git ~/os-src
  cd ~/os-src
  

• A GitHub account (your contribution identity — there is no JIRA).
• Git configured so git commit -s produces a correct Signed-off-by: line:

  git config --global user.name  "Your Real Name"
  git config --global user.email "you@example.com"   # must match your DCO sign-off
  

• A successful local build at least once — see Level 1 Lab 1: Build From Source. You cannot reason about PR quality until you have watched ./gradlew precommit pass or fail on your own machine.
• Optional but recommended: a forum account and a join of the public Slack. You do not need any special status — committer/maintainer status comes later, earned, and is the subject of Chapter 7.

You Have Absorbed This Section When…

Treat this as the gate before declaring the section "read." You have absorbed it when you can:

1. Find any feature in OpenSearch within 10 minutes by tracing from a Rest*Action or Transport*Action, using git log -S, the IDE call hierarchy, and tests as spec.
2. Recover the "why" behind a piece of code: run git blame, find the PR that introduced it, and read that PR's design discussion and the issue it closed.
3. File an issue a maintainer can act on with zero follow-up questions: version, repro, minimal example, expected vs actual.
4. Open a PR that passes ./gradlew precommit and spotlessJavaCheck on the first try, carries a DCO sign-off, adds a CHANGELOG.md entry under [Unreleased], includes tests, and links its issue.
5. Iterate on review the OpenSearch way: push fixups, keep CI green, force-push to squash, re-request review, push back with evidence rather than argue, and apply the right backport label after merge.
6. Predict, for any change, which compatibility surface it touches — wire/index BWC, REST API contract, or performance — and what test or benchmark proves it safe.
7. Explain the difference between a contributor, a maintainer (MAINTAINERS.md), and the TSC, and describe a realistic track record that leads from the first to the second.

The next chapter — Reading a Large OpenSearch Codebase — gives you the navigation strategy you will use through everything that follows.