Skip to content

Request for Comments

Proposals for non-trivial features or changes, debated before implementation begins. Once an RFC is Accepted, the resulting design decisions get captured as one or more ADRs, the implementation plan turns into a Plan, and the feature gets built.

When to write one

Write an RFC for any change that:

  • Touches more than one module
  • Adds a new data model or wire protocol
  • Has multiple plausible designs
  • Locks in a third-party dependency
  • Would be hard to roll back if it doesn't work out

Skip RFCs for one-file fixes, refactors that don't change behaviour, and additions to existing patterns.

Process

  1. Draft. Copy the template, fill it out, name it NNNN-slug.md, set status Draft.
  2. Review. Status In review. MASTER reads it, comments inline, suggests changes.
  3. Decide. Status Accepted (build it) or Rejected (with brief reason).
  4. Implement. Convert the implementation plan to GitHub issues. As decisions lock in during build, write ADRs.
  5. Close. Status Implemented once the work ships. Link to the merged PRs.

Conventions

  • Numbered sequentially across all RFCs (not per status).
  • Use the template.
  • Keep proposals scoped. One RFC, one feature.

Index

No RFCs yet. The first will likely be the multi-merchant cart optimizer (#15) since that's the design with the most plausible alternatives.