matrix-spec-proposals/proposals/4253-spec-process-modify-reject-accepted.md

MSC4253: Modifying or rejecting accepted MSCs

The spec process defines the stages and steps an MSC goes through before becoming actual specification. That process has an awkward accepted-but-not-merged state where the MSC has successfully completed a merge FCP, but has not yet had a spec PR merged to introduce that MSC to the formal specification. During this time, implementations MAY use stable identifiers when speaking the MSC.

The general theory of this stage is that after several rounds of review, the MSC is unlikely to materially change, but the MSC could still change if needed. Typically, this would be most likely to happen during spec PR review.

The spec process does carve out the awkward state for potential modification, but does not describe how modification (or post-acceptance rejection) actually happens though. This proposal clarifies what is believed to be current operating procedure for these two actions.

Proposal

For MSCs which are accepted but not merged (anywhere between finished-final-comment-period with disposition-merge to spec-pr-in-review, inclusive), the following process steps MAY be taken:

1. The SCT may choose to revert FCP acceptance to bring the MSC back to "open, in review" or pull the MSC to rejected instead. The SCT is required to provide guidance to stable implementations, if applicable, for how to handle the change when this happens. It is left as an implementation detail to determine whether an MSC is brought back to in-review or pushed to rejected, and how to enact this process step. This step is known as "post-acceptance rejection", regardless of target state for the affected MSC.

2. Another MSC is required to change the text of the accepted MSC, provided it does two things:

   1. Describe the rationale for the change being made in a dedicated MSC; and
   2. Modify the accepted MSC's actual text in the same GitHub PR. This is to ensure that the change is captured in two ways: with a dedicated, unmerged, MSC and as real rendered text in the event someone is reviewing the accepted MSC's text.

When reviewing spec PRs for accuracy to their respective MSCs, reviewers are encouraged to use the accepted, rendered, text as reference rather than the original GitHub PR for the MSC due to PRs not updating post-merge.

Potential issues

Spec PR reviewers may still miss MSCs which modify another accepted MSC. SCT members should consider when it is more appropriate to use post-acceptance rejection instead of modification. For example, it may be more correct to pull an MSC back to in-review when a modification would be significant or easily forgotten.

Stable implementations of accepted MSCs may be severely affected by either process step. The SCT is expected to work out a plan for how to address those incompatibilities when performing either step.

Alternatives

No significant alternatives.

Security considerations

No significant concerns.

Unstable prefix

No unstable prefix is required for process MSCs.

Dependencies

No direct dependencies, though MSC4252 makes use of this MSC.