Skip to content

RFC process

How substantive design proposals get reviewed before they become ADRs or PRs in TLSStress.Art.

When to write an RFC

Open an RFC (template) before a PR if any of the following is true:

  • The change touches more than one MÓDULO X.Art
  • The change crosses the Tier A / Tier B boundary (per platform/ztp-prem/tier-policy.yaml)
  • The change affects a published API contract (REST, K8s manifest schema, OOBI canonical addressing, sealed-audit envelope)
  • The change introduces or modifies a patent-claim surface (#1..#25)
  • The change adds or removes a Test Kind or Stress Engine
  • The change requires a new ADR

If none of the above is true, skip the RFC and just open a PR.

Lifecycle

  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
  │  Draft   │ →  │  Review  │ →  │ Accepted │ →  │  Shipped │
  └──────────┘    └──────────┘    └──────────┘    └──────────┘
       │              │               │
       │              │               └── ADR filed under docs/ADR/
       │              └── ≥ 5 business days open before accept
       └── Author closes if proposal withdrawn
Phase What happens Owner
Draft RFC issue opened with rfc + triage labels. Title starts with rfc: .... Author
Review Maintainer adds the accepted label OR requests changes. Comments are public. Comment period is ≥ 5 business days so the community has time to weigh in. Maintainer + community
Accepted A corresponding ADR is filed under docs/ADR/ using the next sequential number. The RFC issue is closed with a link to the ADR. The ADR's Status reads Proposed until shipping code lands. Maintainer
Shipped When the implementing PR merges, the ADR's Status flips to Accepted (formalized YYYY-MM-DD with vX.Y.Z — <scaffold note>). The RFC issue stays closed. Maintainer

Minimum content for an RFC

The RFC issue template prompts for these — every RFC must answer them:

  1. Motivation — what user-visible problem this solves
  2. Proposed design — the actual change, in enough detail that a reader can object to specifics
  3. Trade-offs — what we lose by accepting this
  4. Alternatives considered — at least one rejected design + why
  5. Tier classification — Tier A or Tier B impact
  6. Patent-claim surface — does this touch claims #1..#25?
  7. Backwards compatibility — break / migrate / no-op
  8. Documentation impact — which docs need updating

The maintainer will not accept an RFC missing any of the above — not because of rigid bureaucracy, but because each question maps to an audit conversation we want to be able to answer later.

Who can author an RFC

External authors are welcome to propose RFCs. The project is under a noncommercial source-available licence with patent filings in progress (see AUTHORS.md) — code contributions from external authors are not currently accepted, but design discussion is. The maintainer will engage in the issue and, if accepted, may implement the design or invite the author to draft a follow-up PR after the patent prosecution timeline settles.

What's NOT an RFC

Last verified against shipping code: v3.7.0 (2026-05-12).