This repository tracks Requests for Comments (RFCs) for the effectorHQ ecosystem — the formal process for proposing substantive changes to the Effector specification, tooling, and governance.
Not everything needs an RFC. Use this process for:
- Changes to the Effector Spec (new types, manifest fields, lifecycle stages)
- New cross-cutting features that affect multiple repos
- Architectural decisions with long-term consequences
- Breaking changes to published APIs or formats
- Governance changes (decision-making, maintainer roles, community processes)
For bug fixes, documentation improvements, and localized changes — just open a PR on the relevant repo.
Fork this repo. Copy 0000-template.md to text/NNNN-my-proposal.md (use the next available number). Fill in the template. Open a pull request.
The community reviews the RFC via PR comments. The author iterates on the proposal based on feedback. There is no fixed timeline — discussion continues until rough consensus emerges.
A maintainer marks the RFC as either:
- Accepted — Merged into
text/. Implementation can proceed. - Postponed — Good idea, wrong time. The PR stays open for future revisiting.
- Rejected — The PR is closed with a summary of reasons.
Accepted RFCs get a tracking issue in the relevant repo(s). The RFC author is not obligated to implement it — anyone can pick it up.
| RFC | Title | Status |
|---|---|---|
| 0001 | The Effector Specification v0.1.0 | Draft |
This process draws from Rust RFCs, React RFCs, and Ember RFCs. Lightweight by design — we prefer building to writing, but some decisions need shared context first.
CC-BY-4.0 — Same as all effectorHQ documentation.