MSC4253: Modifying or rejecting accepted MSCs #4253
Conversation
turt2live
changed the title
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
None
| 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. |
There was a problem hiding this comment.
Possibly a stupid question but what if using stable identifiers was prohibited until the MSC actually lands in a spec release? That is to say treat it as unstable until it is actually released.
There was a problem hiding this comment.
It'd probably have no effect, as there's no stable implementations. Room versions would fall under this because they require another MSC to actually make them stable.
There was a problem hiding this comment.
This used to be the case but it felt it slowed down ecosystem progress too much by tying features to spec releases. It would simplify handling of version flags though.
There was a problem hiding this comment.
(oh, I failed at reading the question, sorry - clokep's response is much more accurate)
There was a problem hiding this comment.
Maybe with quarterly releases this is no longer necessary, however?
There was a problem hiding this comment.
#3179 should hopefully be a launch point for context.
There was a problem hiding this comment.
Oddly that change wasn't by an MSC?
There was a problem hiding this comment.
Process changes aren't required to have an MSC, but it can be helpful depending on the level of feedback someone is after. In that case, the SCT spent significant time discussing it internally before making the PR, so felt an MSC was not required.
There was a problem hiding this comment.
on the actual topic of stable identifiers: the spec process is supposed to already acknowledge that while developers can switch to stable identifiers, there is still risk in doing so. Developers also can't assume what version of the spec a feature will land in, which makes some/many stable identifier usages less useful without the "unstable stable flag" on /versions.
There was a problem hiding this comment.
Maybe with quarterly releases this is no longer necessary, however?
Yeah, it doesn't seem like an extensive benefit anymore.
It also feels a little odd to me to implement something that is not spec'ed as if it was spec'ed, especially when RFC keywords are often not explicitly nailed down in MSCs.
| accepted, rendered, text as reference rather than the original GitHub PR for the MSC due to PRs not | ||
| updating post-merge. |
There was a problem hiding this comment.
Maybe clarify this means "what's in the main branch"?
| 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. |
There was a problem hiding this comment.
This used to be the case but it felt it slowed down ecosystem progress too much by tying features to spec releases. It would simplify handling of version flags though.
Co-authored-by: Patrick Cloke <[email protected]> Co-authored-by: Alexey Rusakov <[email protected]>
| 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. |
There was a problem hiding this comment.
Why would the mess of modifying an accepted MSC through another be preferable over reopening/replacing the original?
I'm not even sure reopening one is great when that does not really fit the tooling (i.e. GitHub workflow/limitations), when it can be replace with a new one for free?
There was a problem hiding this comment.
Github doesn't allow a merged PR to be reopened. Process-wise, we'd end up always rejecting and rewriting if we were to do that, which is high process for little value compared to just writing a small diff.
Rendered
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published with my role as a member of the SCT.