56 lines
1.4 KiB
Markdown
56 lines
1.4 KiB
Markdown
# ECP-0001: every.channel proposals process
|
|
|
|
Status: Draft
|
|
|
|
## Problem
|
|
|
|
We need a lightweight, consistent way to propose and review changes while keeping the constitution focused on long-lived principles.
|
|
|
|
## Decision
|
|
|
|
Adopt ECP (every.channel proposals) as the primary decision record.
|
|
|
|
Each ECP is a short, versioned document in `evolution/proposals/` that records context, decisions, and rollout steps.
|
|
|
|
### Required sections
|
|
|
|
- Title and status
|
|
- Problem / context
|
|
- Decision
|
|
- Alternatives considered
|
|
- Rollout / teardown plan
|
|
- Open questions (optional)
|
|
|
|
### Status values
|
|
|
|
- Draft
|
|
- Accepted
|
|
- Implemented
|
|
- Superseded
|
|
- Rejected
|
|
|
|
### Numbering
|
|
|
|
- `ECP-0001` is this process.
|
|
- New ECPs increment by 1 and use a short, descriptive slug.
|
|
|
|
### Review and acceptance
|
|
|
|
- Non-trivial changes require an ECP.
|
|
- The founder is the final reviewer and sign-off authority.
|
|
- Once accepted, implementation may proceed or continue.
|
|
|
|
### Identity and signing
|
|
|
|
- Commits must be signed with SSH or age identities (minimum: SSH-signed commits).
|
|
- If signing is not configured, implementation pauses until clarified.
|
|
|
|
## Alternatives considered
|
|
|
|
- Free-form issues: rejected due to loss of decision history.
|
|
- Heavyweight RFCs: rejected due to unnecessary overhead.
|
|
|
|
## Rollout / teardown
|
|
|
|
- Add this process and create initial ECPs.
|
|
- If ECPs become too heavy, supersede this with a lighter process.
|