Communication Channels and Consensus

Before you write a line of code for Firecracker, you need to know where the work happens and how agreement forms — because the answer is narrower, and more public-by-default, than at almost any other large open-source project. There is no public Slack. No Discourse forum. No mailing list you, an external contributor, post to. No weekly community call you dial into. What there is: GitHub issues, GitHub pull requests, a private maintainers email alias, a private security channel, and the CHANGELOG as a shipped record of every user-visible decision. That is the whole communication surface, and it is deliberately small for the same reason the device model is small — fewer surfaces to maintain, fewer places for the "real" decision to hide.

This chapter maps that surface, tells you which channel a given kind of work belongs in, and — most importantly — how to raise a design idea at a project that has no RFC repo and no public design list.

Note: This is the single biggest culture shock for engineers arriving from OpenSearch (public Slack + forum.opensearch.org + community meetings) or an Apache project (dev@ mailing list + JIRA). At Firecracker, GitHub is not one channel among many — it is essentially the only public channel. If a discussion isn't on a GitHub issue or PR, it didn't happen as far as you, an outsider, are concerned. Learn to drive consensus inside that constraint.

The Channel Map

Confirm the current set against the repo rather than trusting this table — links and aliases drift (verify on your branch):

cd ~/fc-src
# Where the project tells you to talk:
rg -n -i "slack|mailing list|discord|forum|mattermost|contact|maintainers@|amazon.com" \
   README.md CONTRIBUTING.md SECURITY.md MAINTAINERS.md FAQ.md
# The security reporting path (private — never a public issue):
sed -n '1,60p' SECURITY.md

The asymmetry to internalize: as an external contributor you read governance via GitHub and the CHANGELOG, you reach the maintainers via issues/PRs (and, rarely, the email alias), and you report security privately. There is no equivalent of OpenSearch's public Slack where you can pull a maintainer into a real-time design chat. Everything routes through asynchronous, public, written GitHub — which is a feature: it forces decisions to be recorded.

Why There's No Slack or Forum (and what that means for you)

This is not an oversight; it is consistent with the single-vendor model (project-governance.md). A foundation project runs a public Slack and a forum because it must build a multi-vendor community — those channels are how strangers from different companies coordinate. Firecracker's core development is a coordinated AWS team that already has internal channels; the public surface exists to receive contributions and report status, not to host a standing community.

For you, the practical consequences are sharp:

• You cannot informally socialize an idea. There is no lobby. Your first public move on a design is a written GitHub issue that has to stand on its own.
• Decisions you can see are decisions that are written down. If a maintainer closes your proposal with a paragraph of reasoning, that paragraph is the decision — there's no back-room you're missing. Conversely, if the "why" of a maintainer choice isn't on a public issue, you may genuinely not have access to it, and pressing for it rarely helps.
• Response latency is real and asynchronous. A team owns this as a job, not a hobby, but they triage in batches. A well-formed issue gets a faster, better response than a vague one because it costs the maintainer less to act on. Write for the reader who has thirty other issues open.

How to Raise a Design Idea (the RFC-shaped issue)

Firecracker has no RFCs/ repo and no design mailing list. The mechanism for proposing something non-trivial is a well-structured GitHub issue — an RFC in everything but name — opened before you write the implementation PR. This is the most important workflow in this chapter, because the single most common way a strong engineer wastes a week on Firecracker is building a feature PR for a change the maintainers would never accept (see maintainer-mindset.md for why they decline).

flowchart TD
    A[You have a design idea] --> B{Is it a vulnerability?}
    B -->|Yes| C[Report privately to AWS Security per SECURITY.md - STOP]
    B -->|No| D{Trivial, obviously-correct fix?}
    D -->|Yes| E[Open a focused PR directly, link a bug issue]
    D -->|No: new behavior, API, device, format| F[Open a design-proposal ISSUE first]
    F --> G[State problem, threat-model impact, alternatives, compat impact]
    G --> H[Maintainer triage: aligned? scope OK? fits CHARTER.md?]
    H -->|Yes, with guidance| I[Now write the PR, referencing the issue]
    H -->|No / not now| J[Decision recorded on the issue - do not just open a PR anyway]

A design-proposal issue that respects the maintainers' time has this shape — and pre-empting their questions is exactly what gets you a real answer instead of silence:

1. The problem, concretely. What can't you do today; what breaks; who is affected. Not "it would be nice to have X."
2. Threat-model and attack-surface impact. Firecracker maintainers think about this first. If your proposal adds a device, a syscall, or host-reachable parsing, say so up front and argue why it's worth it. Read the minimal-device-model philosophy before you write this paragraph.
3. Compatibility impact. Does it touch the REST API (src/firecracker/swagger/firecracker.yaml), the snapshot format, or the config-file schema? Those are near-permanent contracts (maintainer-mindset.md).
4. Alternatives considered, including "do nothing" and "do this in rust-vmm / a downstream orchestrator instead." Maintainers often redirect features out of the VMM core.
5. A rough implementation sketch so they can judge the blast radius — not a finished PR.

cd ~/fc-src
# Read how others framed accepted proposals before you write yours:
gh issue list --label "Type: Enhancement" --state all --limit 20
gh issue list --search "proposal OR RFC OR design in:title" --state all --limit 20
# And how proposals get declined — read the reasoning, it's the real curriculum:
gh issue list --state closed --label "Type: Enhancement" --limit 20

Tip: The fastest way to learn what will be accepted is to read what was rejected and why. The closing comment on a declined enhancement is often a clearer statement of Firecracker's scope than CHARTER.md itself. Treat closed issues as documentation.

The CHANGELOG as a Communication Artifact

CHANGELOG.md is not a release-notes afterthought — it is a primary communication channel, and one you contribute to directly. Every user-visible change adds an entry, and at release time those entries are the release notes (release-process.md). Two consequences:

• Your PR is incomplete without its CHANGELOG line. A user-facing change with no CHANGELOG entry is invisible to the people downstream (Lambda, Fargate, firecracker-containerd, Kata) who read the CHANGELOG to decide whether to upgrade. Reviewers will ask for it.
• The CHANGELOG is how compatibility intent is announced. Deprecations, removals, and behavioral changes are communicated here before and as they ship. Reading the CHANGELOG top-to-bottom is the fastest way to learn what the maintainers consider a breaking change.

cd ~/fc-src
# The structure you must match (Keep-a-Changelog-style sections; verify on your branch):
sed -n '1,60p' CHANGELOG.md
# See how breaking changes and deprecations are worded — copy that register:
rg -n -i "deprecat|removed|breaking|no longer|renamed" CHANGELOG.md | head -30

Write CHANGELOG entries for the operator reading release notes, not for yourself: name the user-visible behavior, link the PR, and put it under the right heading (Added / Changed / Fixed / Deprecated / Removed / Security). The mechanics are covered in code-style-trust.md; the point here is that it's a communication act.

Security Disclosures Are Private — Always

This deserves its own warning because getting it wrong is the one communication mistake that can genuinely harm users.

Warning: A Firecracker security vulnerability is never a public GitHub issue, PR, or discussion. It goes privately to AWS Security via the process in SECURITY.md. Filing a public issue for a guest-escape or info-leak bug hands a working exploit to every attacker watching the repo before a fix exists. This is the opposite of how you handle a normal bug, and it is non-negotiable.

The flow, end to end:

You find a security bug
        │
        ▼
Report PRIVATELY per SECURITY.md (AWS Security)  ──►  acknowledged, triaged privately
        │
        ▼
Fix developed on a private branch by the maintainers
        │
        ▼
Coordinated release across supported lines  ──►  e.g. the PCI-transport CVE shipped as 1.14.4 / 1.15.1
        │
        ▼
Public disclosure: CHANGELOG "Security" entry, GitHub Security Advisory, CVE

You can read the output of that pipeline — published advisories — to learn how Firecracker communicates fixed vulnerabilities:

cd ~/fc-src
gh api repos/firecracker-microvm/firecracker/security-advisories --jq '.[].summary' 2>/dev/null | head
rg -n -i "CVE-|security advisory|GHSA" CHANGELOG.md | head

The contrast with the rest of this chapter is the lesson: everything else is public-by-default; security is private-by-default. Knowing which mode a given communication belongs in is itself a mark of a contributor the maintainers trust.

Where Consensus Actually Forms

Pulling it together: consensus at Firecracker forms in the open, on a GitHub issue or PR, recorded in writing, with the AWS maintainers as the deciding voice. There is no vote, no quorum, no foundation to appeal to. The artifact you watch is a maintainer's comment, an approval, a merge, and a CHANGELOG line — not an email thread passing. Your leverage is the quality and clarity of your written case, and the track record behind your name when you make it (code-style-trust.md). At a project with this little communication surface, how well you write a GitHub issue is a larger part of your influence than at any project with a Slack to fall back on.

Prove You Understand This

1. List every public communication channel Firecracker offers an external contributor, and the one private one. Which channel is conspicuously absent compared to OpenSearch, and why?
2. You have an idea for a new virtio device. What is the first thing you do, and what five things does that artifact need to contain to get a real response?
3. Why does a decision you can't find the reasoning for probably not have hidden reasoning you're being denied — and how does that follow from the single-vendor model?
4. Where do CHANGELOG entries come from, who reads them downstream, and why is a missing one a review blocker?
5. You discover what looks like a guest-to-host info leak. Walk through exactly what you do and do not do, in order.
6. Explain why "how well you write a GitHub issue" carries more weight at Firecracker than at a project with a public Slack.

Next: The GitHub PR Review Process — what happens to the PR you open once you've built consensus on the issue.