Real Issues & Roadmap: Finding Work That Matters

The gap between a typo-fixer and a contributor the maintainers learn to trust is not skill — you already have skill. It is leverage: the ability to find the work that actually matters to the project and to engage it in a way that builds standing. Firecracker is a single-vendor project with a small, busy maintainer team. They do not have time to hand you a problem. They do publish, in the open, exactly where the project is going and what they want help with — if you know how to read it.

This chapter is the practical playbook. It teaches you the four sources of design signal (GitHub labels, the docs/ design notes, the CHANGELOG, the code itself), how to triage them into something you can own, and how to engage so that your first comment on a hard issue lands like a contributor's and not a drive-by.

Note: Everything below uses live commands against the real repo. Install and authenticate the GitHub CLI once (gh auth login) and clone the repo (git clone https://github.com/firecracker-microvm/firecracker). Run the commands. A roadmap you have not queried yourself is just a rumor.

Source 1: the GitHub label vocabulary

Firecracker's labels are a controlled vocabulary, not free-form tags. Learn it and the issue tracker becomes navigable. Confirm the current set on your own:

gh label list --repo firecracker-microvm/firecracker --limit 60

The labels that matter for finding leverage, grouped by what they tell you:

The query that finds genuinely impactful, active work:

# Roadmap-tracked AND open — the committed direction of the project.
gh issue list --repo firecracker-microvm/firecracker \
  --label "Roadmap: Tracked" --state open --limit 50

# Performance opportunities — measurable, valued, and a clear way to show depth.
gh issue list --repo firecracker-microvm/firecracker \
  --label "Type: Performance" --state open --limit 50

# Enhancements that are also roadmap-tracked: features they actually want.
gh issue list --repo firecracker-microvm/firecracker \
  --search "label:\"Roadmap: Tracked\" label:\"Type: Enhancement\" state:open"

Tip: Sort by activity, not creation date. A roadmap issue with comments in the last month is alive; one untouched for a year is a graveyard you should read for context but not pick. gh issue list ... --search "sort:updated-desc".

Source 2: the docs/ design notes

This is the source most newcomers miss, and it is the single best predictor of near-future work. Firecracker frequently merges a design document before the feature is generally available. A design note in docs/ for a feature that is not yet on by default is a map of an open problem, written by the people who will review your PR.

cd ~/src/firecracker
ls docs/

Read these as direction signals (verify which are still "preview" on your branch — the CHANGELOG will say):

The --enable-pci virtio-PCI transport is another in-flight area: it exists, it is opt-in, and it had a real CVE (CVE-2026-5747, fixed in 1.14.4 / 1.15.1 — verify on your branch). A maturing transport with a recent security history is precisely where careful contributors are wanted.

When you find a design note that excites you, read it with the matching code and the matching open issues:

# Tie a design note to its code and its issues.
rg -rn "virtio.mem|VirtioMem|hotplug" src/vmm/src/devices/ | head
gh issue list --repo firecracker-microvm/firecracker --search "virtio-mem in:title,body state:open"

Source 3: the CHANGELOG as a trajectory

CHANGELOG.md is the narrated history and future of the project. Read it as a trajectory, not a reference. Two reading techniques:

# The future: what's landing now.
sed -n '/## \[Unreleased\]/,/## \[/p' CHANGELOG.md    # or just open and read the top

# The pattern: how a feature graduates. Grep its lifetime across the log.
rg -n "snapshot|diff|track_dirty|virtio-mem|pci|io_uring" CHANGELOG.md | head -40

What the CHANGELOG tells you that the issue tracker does not:

• Deprecations signal where the design is being cleaned up. The enable_diff_snapshots → track_dirty_pages rename, or the deprecation of the standalone mem_file_path on load, both say "the snapshot API is being hardened" — a domain with ongoing, reviewable work.
• "Developer preview" → "GA" transitions tell you a subsystem is stabilizing and therefore wants test coverage, edge-case fixes, and documentation. Diff snapshots being in developer preview (verify) is an open invitation.
• New endpoints (e.g. /hotplug/memory, /pmem/{id}, balloon hinting) tell you which devices and capabilities are actively growing.

Source 4: the code's own TODOs and the test gaps

The last source is the codebase itself. Two cheap, high-yield searches:

# Honest TODO/FIXME left by maintainers — often a scoped, real task.
rg -n "TODO|FIXME|XXX" src/vmm/src/ | rg -iv "test" | head -40

# Kani formal-verification harnesses and fuzz targets — a deep-end on-ramp.
rg -rln "kani::proof|#\[cfg\(kani\)\]" src/ | head
ls tests/ && rg -n "fuzz" docs/fuzzing.md | head

A TODO next to a comment like "this is O(n) but n is small" is a performance issue waiting to be filed. A device with thin test coverage is an integration-test PR waiting to be written. The maintainers reward PRs that close a gap they already know about far more than novel features.

From signal to contribution: a triage flow

flowchart TD
    Start["pick a domain you find genuinely interesting"] --> Read["read its docs/ note + deep dive"]
    Read --> Issues["gh issue list on that domain's label/keywords"]
    Issues --> Triage{"alive? bounded? you understand it?"}
    Triage -- no --> Read
    Triage -- yes --> Repro["reproduce / instrument on a real checkout"]
    Repro --> Comment["comment with evidence, not opinion"]
    Comment --> Own["claim a sub-task; deliver a tested PR"]
    Own --> Sustain["repeat in the SAME domain — become the person for it"]

The last box is the whole game. Pick one area and own it. A contributor who files three thoughtful issues and two solid PRs in the snapshot subsystem becomes, within a few months, "the snapshot person" the maintainers route questions to. Five scattered PRs across five subsystems make you forgettable. Depth compounds; breadth does not.

How to engage a hard issue without burning credibility

The maintainers can tell in one comment whether you have read the code. Make your first comment on a non-trivial issue carry evidence:

# Before you comment, arm yourself with reproduction + code evidence:
tools/devtool build --release
# ... reproduce the reported behavior, capture output ...
rg -rn "<the relevant type or fn>" src/vmm/src/   # quote it by role, not line number

A first comment that says "I reproduced this on commit abc123 with these commands; the relevant logic is in <file>'s <fn>; the trade-off seems to be X vs Y; would a fix that does Z be acceptable, or does it conflict with the snapshot versioning guarantee?" marks you immediately as someone worth investing review time in. That is leverage.

What good ownership looks like

A contributor who has owned an area can do all of this without being asked:

• Knows the relevant docs/ note, deep dive, and code paths cold, and keeps the doc updated when the code changes.
• Watches the CHANGELOG and the relevant labels and triages new issues in the area.
• Writes the integration test for the edge case before the bug is filed.
• Reviews other people's PRs in the area substantively (the fastest way to earn maintainer trust short of writing code).
• Respects the constraints table from the section overview and can explain why a tempting feature does not fit.

Every chapter that follows is a candidate area to own. Read them, pick the one that grabs you, run its commands, and start.

Next: pick a domain. The deepest and most-actively-developed is Snapshotting at Scale. If you prefer raw performance, go to Boot-Time Optimization or I/O Engines.