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

[ShadowJonathan]

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.

[ShadowJonathan]

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".

I would also like to mention that, due to the (unfortunate) situation of the ecosystem today, with most resources and time being donated from Element/New Vector for authoring MSCs, and the close working relationship of the SCT and Element developers, that this gives Element an unhealthy/unfair advantage over other implementations, both socially and "economically" (for other developers spending resources to implement this in X time).

---

Another data point; Ruma currently does not wish to stablize room v9 (i.e. making it available without the unstable-pre-spec flag), or any other MSC, until it has been formalised. This largely contributed to the discussion in matrix-org/matrix-spec-proposals#3589.

[turt2live]

To address the unhealthy Element relationship comment: The SCT is required to act in favour of Matrix, not Element or any other player. Now, Element does have the budget and resources to make a lot of features happen, but it's also worth noting that Element has its own priorities outside of Matrix which is exactly why it doesn't get privileged, even by employees.

As a concrete example: The Element clients don't have knocking or refresh tokens yet, despite both being worked on extensively by Element the company. Element is able to publish a large volume of MSCs, but that still doesn't give them preferential treatment - typically though, the MSCs align with the Matrix mission and get reviewed as such.

It's also strongly in Element's interest that Matrix progress on its own accord, which extends into resourcing and time commitments for the SCT members. While employed by Element, it's still important that SCT members operate their volunteer hat when needed and that Element carve time out for the employed SCT members. The balance of how much time the SCT has is constantly being adjusted and analyzed, and in the new year we expect to dedicate about 4x more time (on average) towards the spec. Individual members have different ratios because not everyone fits into a generalized statement :)

[richvdh]

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.

It seems like we need to clarify this more generally; it is not consistent with my understanding, which is: implementations can implement MSCs which have passed FCP (on the grounds that the only thing stopping them being in the formal spec is the time to write a PR), but are under no obligation to.

Indeed, I don't think we've ever formally specified a timeframe in which implementations are expected to implement a new feature in the spec.

[ShadowJonathan]

Alright, in that case i'll rephrase my request; to have that expectation be only after formalisation (after spec PR passes)