Capstone Project Portfolio

The guided Capstone walks you through one contribution end-to-end: pick a real open issue, reproduce it, trace it, fix it, land it, write it up. That is the minimum viable contributor experience — one PR, scaffolded by ten step-chapters that hold your hand through the workflow.

This section is the next thing. It is a portfolio of eight larger, open-ended project briefs, each grounded in a real OpenSearch / k-NN / Lucene issue or RFC. Where the guided Capstone gives you a process with a small bug poured into it, these briefs give you a meaningful slice of an open engineering problem and ask you to scope, design, build, and (for several) land it upstream. They are deliberately harder, deliberately less scaffolded, and deliberately aimed at the advanced layer this expansion is about: vectors, scale, Lucene internals, and the search engine under real load.

You do not do all eight. You do one or two, well. A single finished brief — a designed, tested, benchmarked, upstreamed change — is worth more on a contributor track than a dozen drive-by typo fixes. The portfolio exists so you can choose a problem that matches the muscle you want to build next.

Note: Several of these are explicitly "land it upstream" projects. Project 1 (k-NN), Project 4 (Apache Lucene), Project 5 (star-tree), and Project 8 (segment-replication observability) each have a credible path to a real merged PR in opensearch-project/k-NN, opensearch-project/OpenSearch, or apache/lucene. The others are "build the capability locally to maintainer quality, then decide with the area maintainers whether to upstream the scoped slice." Both are real work. Neither is busywork.

What this is (and what it is not)

Each brief follows a consistent shape so you can compare and plan:

1. Problem & motivation — what is broken or missing, and why it matters.
2. Real-world grounding — the actual issue/RFC, linked by full URL.
3. Subsystems you'll touch — the org.opensearch.* / org.apache.lucene.* / org.opensearch.knn.* classes and the deep dives that cover them.
4. Phased plan — Phase 1..N, from a small scoped slice you can finish in a weekend to the full feature, with concrete tasks, grep targets, and code sketches.
5. Deliverables — a - [ ] checklist.
6. Difficulty & time.
7. Stretch goals.
8. Evaluation — tied back to the rubric.
9. How to turn this into a real contribution — the upstreaming path.

The eight projects

Projects 1–4 are written out in full in this section. Projects 5–8 are sketched in the table and have their own briefs (project-05-… through project-08-…); they share the same nine-part shape. If you want one and the brief is not yet expanded, the grounding RFCs are in Real Issues and RFCs.

Warning: "Difficulty" here is engineering difficulty, not how mergeable the result is. Project 6 (benchmark harness) is "Medium" to build but extremely mergeable; Project 5 (star-tree) is "Very hard" and a scoped slice of it is the only realistic upstream target. Read the "How to turn this into a real contribution" section of any brief before you start, so you scope to what can actually land.

How to pick one

Pick along three axes, in this order:

1. The subsystem you want to own. If you finished the k-NN chapters and want vectors, take 1 or 6. If you came through shard allocation and coordination, take 2. If search execution and parallelism is your thing, take 3. If you want to touch Apache Lucene directly, take 4.
2. The skill the rubric says is your weakest. The rubric's "What to Do With a Low Score" table maps a weak dimension to a kind of next contribution. Weak on testing? Project 6 is almost entirely measurement discipline. Weak on execution-path mastery? Project 3 forces you to trace the slicing decision through Lucene and back. Weak on implementation quality? Project 1's Phase 1 is a deliberately tiny, minimum-diff slice.
3. Whether you want a merge or a capability. Want a real merged PR on your GitHub profile in 4–6 weeks? Take 4 (Lucene), 6 (k-NN tooling), or the scoped Phase-1 slice of 1. Want to build a hard capability locally and possibly RFC it? Take 2 or 7.

Do not pick by "which sounds most impressive." The impressive thing is a finished brief with numbers and a clean diff, whatever the topic.

The shared deliverable shape

Every brief, regardless of repo, produces the same core artifacts — the same ones the guided Capstone demands, adapted for a feature rather than a bug fix:

• A design note (capstone-work/design.md in your fork): problem, constraints, the approach you chose, the approaches you rejected and why. For anything touching wire format, public API, or a new setting, this is what you would post to an RFC or the issue thread before writing code.
• A scoped, minimum-diff implementation on a feature branch. Even a feature is a sequence of small, reviewable commits — not one 2,000-line drop.
• Tests at the lowest viable level: unit tests (OpenSearchTestCase / Lucene's LuceneTestCase), and integration tests (OpenSearchIntegTestCase / InternalTestCluster) only where behavior is genuinely end-to-end. Serialization round-trip tests (AbstractWireSerializingTestCase) iff you changed the wire.
• Numbers, where the project is about performance (3, 6, parts of 1): a JMH microbenchmark and/or an OpenSearch Benchmark macro run, before/after, with the recall metric stated for any ANN change.
• A validation report (capstone-work/validation.md): the ./gradlew check / precommit output, the test commands, the seeds you ran.
• An upstreaming decision: either a real PR (DCO-signed for OpenSearch/k-NN; ASF-style for Lucene) or a written "here is the scoped slice I would propose, and here is the issue/RFC comment I would open it under."
• A write-up (500–1000 words): the same engineering write-up the guided Capstone asks for, because the investigation is the durable artifact.

Note: The DCO / git commit -s / CHANGELOG.md / backport-bot model from the guided Capstone applies unchanged to OpenSearch and k-NN PRs. Apache Lucene is different — it uses a CHANGES.txt entry and the ASF's PR conventions, no DCO sign-off line. Project 4 covers that difference in detail.

How these map to the rubric

You self-grade every project against the same 100-point evaluation rubric you used for the guided Capstone. The seven dimensions translate cleanly from "bug fix" to "feature":

The tier thresholds are identical. A finished portfolio project at 90+ is maintainer-grade work in an advanced area — exactly the track record that, sustained, gets noticed. Score yourself honestly; the rubric's two rules (no interpolation upward, one independent reviewer) still bind.

Before you start any brief

1. You finished the guided Capstone, or you are confident you can run its workflow (reproduce → trace → fix → test → PR) without the step-chapters open.
2. You can build the relevant repo from source:
   • OpenSearch: ./gradlew assemble (covered throughout Levels 1–9).
   • k-NN: the native JNI build via CMake — see k-NN native integration and the lab-k1-build-knn-from-source lab.
   • Apache Lucene: ./gradlew check on apache/lucene — see the Lucene contribution lab.
3. You read the brief's "How to turn this into a real contribution" section first, so you scope Phase 1 to something that can actually land or be RFC'd.

Then pick one. Project 1 is the natural start if you came through the vector chapters; Project 4 is the natural start if you want a real upstream merge with the least cross-plugin surface area.