RFC: Simplify RFC voting by removing mandatory discussion windows and making REVISE stop the current snapshot

Problem

The current RFC process still creates two kinds of unnecessary friction.

First, every RFC must wait through a fixed discussion period before voting: 48 hours for ordinary RFCs and 72 hours for exceptional-unanimous RFCs. In practice, that timer often does not produce more review. Some proposals sit idle until the vote opens, while proposals that are already stable still wait because the rule says they must.

Second, the current REVISE rule does not match how Core has actually used revision ballots. FND-003 Rev. 15 says REVISE withholds approval but does not veto. With two-thirds approval and silence-as-approval after quorum, that can make a REVISE ballot help a proposal pass. For example, with four active Core voters, one explicit APPROVE, one explicit REVISE, and two silent voters currently produces three approvals out of four after quorum. That is mathematically coherent, but it is not what maintainers mean when they say the current snapshot needs revision.

The process should match the practical rule Core is already moving toward: a vote tests one snapshot. If an eligible Core voter says that snapshot needs revision, the vote on that snapshot stops and the author or maintainer revises the body.

Proposal

Revise the RFC process so that:

1. There is no mandatory minimum discussion period before an RFC vote.
2. An RFC vote may open when the proposal has a visible stable snapshot, the vote opener identifies the RFC trigger, and a Core contributor is willing to put that snapshot to vote. The vote-opening comment records the trigger and why the snapshot is ready for a Core decision.
3. Discussion remains encouraged before and during voting, but it is a readiness state, not a timer.
4. REVISE is a snapshot-stopping ballot. A valid REVISE from an eligible Core voter immediately ends the vote on the current snapshot and returns the RFC to revision/discussion.
5. A valid REVISE ballot must name the affected contract or body term, the concrete body change or decision needed, and why the ambiguity prevents approval.
6. Non-blocking concerns should use APPROVE with implementation boundaries or follow-up notes, not REVISE.
7. After a revised body establishes a new stable snapshot, that snapshot may return to vote immediately or in the next coordinated vote batch. A vote batch is scheduling only; it does not change each RFC's snapshot, electorate, deadline, or ballot rules. No automatic 48-hour or 72-hour waiting period restarts merely because the body changed.
8. Explicit ballots on an unchanged deferred snapshot carry forward only when the continuation or reopening record names the unchanged snapshot, lists the carried ballots, sets an exact UTC deadline, and the voter has not withdrawn or replaced that ballot. The new deadline is normally 72 hours from the continuation or reopening record. Any material body change creates a new snapshot and does not inherit earlier approvals.
9. REJECT, quorum, two-thirds approval, silence-as-approval after quorum, exceptional unanimity, immutable vote snapshots, 72-hour vote windows, and active-electorate rules otherwise remain as defined by FND-003 Rev. 15 unless specifically changed here.

Design sketch

The revised lifecycle is:

1. AUTHOR opens an RFC issue using the RFC issue template,
   naming the RFC trigger the proposal crosses.
           |
2. RFC DISCUSSION / SNAPSHOT PREPARATION
   Anyone can comment. The author or a maintainer revises the body until a
   Core contributor is willing to open a vote on a stable snapshot.
           |
3. VOTE OPENS against an immutable snapshot.
   The vote-opening comment records:
     - the snapshot digest or immutable artifact
     - the assigned active electorate, with inactive Core notified for re-entry
     - the threshold and why it applies
     - that quorum requires two explicit ballots
     - the exact UTC deadline, normally 72 hours after opening
           |
4. CORE TEAM BALLOTS, one of:
     APPROVE  accept the snapshot as written, optionally with implementation boundaries
     REVISE   stop this snapshot and request a concrete body change
     REJECT   reject the proposal, with a specific blocking reason
           |
5. OUTCOME
     a. Valid eligible REVISE ballot before deadline  -> RETURNED TO REVISION
     b. Fewer than two explicit ballots by deadline   -> DEFERRED
     c. Quorum met and any final ballot REJECT        -> REJECTED
     d. Quorum met, no valid REVISE/REJECT, two-thirds
        approving explicitly or by silence            -> ACCEPTED
     e. Otherwise                                     -> DEFERRED

A REVISE ballot is valid when it names the affected contract or body term, the concrete body change or decision needed, and why the ambiguity prevents approval. A REVISE that names a body section or term and a requested change is valid on its face. The vote opener may ask for clarification, but may not set aside that ballot alone; if validity is disputed, one other Core contributor must agree that the ballot is invalid or the ballot stands. If the ballot only says "revise" without a reason, the vote opener asks for clarification; the vote does not stop and the ballot does not count toward quorum unless the voter cures it before the deadline or another Core contributor confirms it identifies a real body blocker. A valid REVISE is terminal for that snapshot and cannot be superseded by a later APPROVE inside the same stopped vote. Other ballots remain supersedable while the vote remains open.

A valid REVISE before the deadline stops the snapshot even if other voters have already approved or the apparent threshold would otherwise be met. Silence-as-approval is evaluated only at the deadline for a vote that remains open and has no valid REVISE or REJECT; silence never overrides a stopped snapshot.

If a voter wants a smaller correction that does not change what Core is approving, the expected ballot is APPROVE with a boundary note. Examples include implementation-test expectations, PR sizing, minor wording polish, or follow-up issue requests that do not change the accepted contract.

Body edits before a vote do not need a waiting period. The vote opener is responsible for deciding whether the body is stable enough to snapshot. Body edits after a vote opens either stop the current vote as a material replacement or remain outside the voted snapshot until the next revision.

An unchanged deferred snapshot may return to vote without repeating discussion. The continuation or reopening record must name the same snapshot, list the carried ballots, and set a new exact UTC deadline, normally 72 hours from that record. Explicit ballots from the earlier vote carry forward only when the continuation or reopening record lists them against the same snapshot and the voter has not withdrawn or replaced them. Carried ballots count as explicit ballots for that snapshot; a materially revised snapshot starts fresh.

This proposal should update:

• docs/book/src/foundations/fnd-003-governance.md;
• docs/book/src/contributing/rfcs.md;
• the RFC review workflow used by maintainers and review assistants;
• any vote-opening or vote-closing templates that still describe REVISE as non-vetoing.

Alternatives considered

Keep the current FND-003 Rev. 15 process. This preserves a formal minimum discussion window and mathematically consistent vote counting, but it keeps the failure mode where a REVISE ballot can help satisfy quorum and let silence approve a snapshot the voter said needs revision.

Keep the discussion timer but make REVISE stop the vote. This fixes the REVISE problem but keeps the least useful part of the current process. The project already has a 72-hour vote window for review and objection once a snapshot is proposed.

Keep REVISE non-vetoing but remove silence-as-approval. This avoids accidental approval through silence, but it reintroduces stalled votes as the normal failure mode. Core has already chosen silence-as-approval after quorum to keep the queue moving.

Allow REVISE to stop only with two supporting voters. This would reduce individual blocking power, but it makes the meaning of REVISE fuzzy again and risks approving an unstable snapshot over a real contract objection.

Non-goals

• Change which issues require RFCs.
• Change the 72-hour vote duration.
• Change the active-electorate or two-ballot quorum rules.
• Change the default two-thirds threshold or the exceptional-unanimity threshold.
• Let vague REVISE ballots block indefinitely without naming the required body change.
• Turn implementation-level polish into a reason to stop an otherwise stable RFC vote.
• Reopen or rejudge already accepted RFCs merely because this process changes.

Risks and mitigations

• Risk: votes open before enough people have noticed the RFC. Mitigation: the vote still runs for 72 hours, records the electorate publicly, assigns/notifies active Core, and allows any eligible Core voter to stop the snapshot with a concrete REVISE or reject it with a specific reason.
• Risk: REVISE becomes an easy delay button. Mitigation: a REVISE ballot must name the body change or ambiguity that blocks approval. Minor implementation expectations should be recorded as APPROVE boundaries instead.
• Risk: removing the timer reduces community input. Mitigation: discussion remains open from issue filing through vote, and any material body change creates a new snapshot. The timer is removed because it has not been the part that produces useful review.
• Risk: authors receive repeated revision rounds. Mitigation: reviewers should distinguish vote-contract blockers from implementation boundaries before casting REVISE, and follow-up REVISE ballots should explain whether the issue is new or a missed prior request. The revision record should map each blocker to the body change that resolves it before the snapshot returns to vote.
• Risk: process changes while votes are already open. Mitigation: apply this RFC only to votes opened after its acceptance unless the vote-opening comment explicitly opts into the new rule by Core agreement.

Breaking change?

Yes - existing configurations, APIs, or defaults change

Decision and revisit surface

This RFC asks Core to ratify a narrower RFC process:

1. No mandatory pre-vote discussion timer.
2. Vote opening depends on a stable visible snapshot and Core willingness to vote.
3. REVISE stops the current snapshot once it names a concrete body change or blocking ambiguity.
4. Revised snapshots can return to vote without an automatic waiting period.
5. Vague REVISE ballots do not stop a vote until cured with a concrete snapshot blocker.
6. Unchanged deferred snapshots may carry explicit ballots forward only when the continuation or reopening record lists those ballots against the same snapshot and sets a new exact UTC deadline.
7. APPROVE with boundaries is the expected path for non-blocking implementation concerns.

If accepted, the implementation PR should update FND-003, the contributor RFC guide, and maintainer workflow templates. The new process applies prospectively to votes opened after the documentation PR lands, unless Core explicitly records earlier use on a specific issue.

Revisit this decision if votes begin opening without meaningful review, REVISE ballots become vague blockers, or accepted RFCs repeatedly require immediate corrective revisions.

Related work:

• #9496: accepted Rev. 15 RFC process overhaul.
• #9499: merged docs PR that promoted Rev. 15 to FND-003 and the contributor RFC guide.
• #8692: live maintainer decision queue where the current REVISE and discussion-timer friction has shown up during batch voting.

Data hygiene checks

• I removed personal/sensitive data from examples, payloads, and logs.