RFC process
For changes that affect public API surface, runtime semantics, or anything described in the README or docs, please open an RFC issue before writing the code. This avoids the “weeks of work, rejected at review” outcome that hurts contributors and maintainers equally.
When you need an RFC
Section titled “When you need an RFC”- New public export in any
@triggery/*package. - Breaking change to an existing public API.
- Change in runtime semantics (dispatch order, cascade behaviour, scheduler defaults, inspector format).
- New middleware hook.
- Renaming or moving any documented option.
You don’t need an RFC for:
- Bug fixes that restore documented behaviour.
- Internal refactors with no public-API change.
- Doc improvements, test additions, dependency bumps.
The flow
Section titled “The flow”- Open an RFC issue using the rfc.yml template. Sections to fill in:
- Problem — what’s wrong today, with a concrete user story.
- Proposal — the change, as small as possible.
- Alternatives — at least one rejected alternative with the reason.
- Migration — how do existing users get to the new shape? A codemod is preferred where mechanical.
- Get ≥ 1 maintainer approval on the design before writing code. The approval is on the issue thread — not in the PR.
- Open a PR that implements the approved design and link it to the RFC issue with
Closes #N. - Reviewers focus on implementation — the design was already accepted. Material design changes during review mean re-opening the RFC.
Comment window
Section titled “Comment window”Non-urgent RFCs sit for at least 7 days to give the community time to weigh in. Security-sensitive changes can move faster, at the project lead’s discretion.
Lazy consensus
Section titled “Lazy consensus”If no maintainer objects within 72 hours of an RFC reaching “ready to merge” status, the change is accepted. Objections re-open the discussion. The project lead breaks ties when consensus fails — see GOVERNANCE.md.
After 1.0
Section titled “After 1.0”Post-1.0, breaking changes ship only in major versions with at least 30 days of pre-release window for community testing. Pre-1.0, minor versions can include breaking changes — codemods are shipped where mechanical.