Consider changing the point in the spec process when implementations are expected to follow the spec.

MSC matrix-org/matrix-spec-proposals#3589 generated some discussion about spec stabilisation.

Currently, per @turt2live;

Implementations are generally expected to implement [MSCs which passed FCP] before it is released in the spec, and indeed before we even specify it formally.

There are 4 steps a MSC goes through through its lifetime;

• MSC in-proposal, this is often called "unstable"
• MSC post-FCP, this is called "stable"
• Spec PR passed, i'll call this "formal"
• New matrix version released with MSC-specified feature/change, i'll call this "released"

Currently, community matrix projects are expected to have implemented the spec whenever it's marked "stable". However, as i note in a comment on above MSC, this is non-ideal, and puts a lot of pressure on community projects to scour and search MSC texts, unstable reference implementations, and author reasoning to piece together a "it must work this way" idea.

It is then expected that all implementations have either a. followed the tides and turns of the MSC, and already have a half-ready implementation to convert, or b. somehow have the energy and will to scramble together an implementation based off of the text of the MSC.

The hazard with the latter one is that this will make implementations often miss out on gotchas that the original MSC authors, SCT, and spec scribes know amongst themselves from resolving threads, but which the community must then discover for themselves.

Another problem with saying "it is done, it is stable" upon FCP, is that it burdens community projects with heavy social expectations of "oh you're not implementing X yet?", this gives heavy leeway to projects that the original authors came from, or the projects which can afford implementing these features in "double-time".

The whole idea of the matrix implementation is that there is a formal, single, spec. So i'm requesting here that the burden on community implementations to definitively implement something is shifted to after a spec PR has been passed and formalised, when the spec is "formal".

This would make the community feedback much more clear, and allows the period between stabilisation and formalisation to be a grace period for wide-spread implementation.

Start with MSC matrix-org/matrix-spec-proposals#3589 and the linked discussion about spec stabilisation. Determine the agreed implementation expectation and the point at which it should change; done means the process decision is resolved and reflected in the applicable project guidance.