Commit Graph

15 Commits (9ede29a01dae856ecb0649e5e85e2f6e2ccbea19)

Author SHA1 Message Date
Richard van der Hoff a164302164
Get rid of the `proprosal-in-review` label (#1036)
Everything is in review. We may as well just use the draft state for WIP stuff.
3 years ago
Richard van der Hoff 614680675f
Fix broken links to `matrix-doc` (#1032)
The spec has moved to https://github.com/matrix-org/matrix-spec, so there were
a lot of broken links here.
3 years ago
Catalan Lover 188eba6969
Correct several occurances of the old repo (#1031)
This PR aims to correct several occurances of the old repo link in proposals.md 

I have not corrected all of them as i do not wish to say that i know the correct way we should word things in these situations. The primary changes are replacing all mentions of contributing.rst with the updated link that will work. 

I also changed the line about related MSCs or Doc issues to be Spec issues since i think this is a clear enough case for me to be willing to guess what is appropriate.
3 years ago
Matthew Hodgson c151353956 s/master/main/g otherwise we link to stale content 3 years ago
Andrew Morgan fca6992cd9 Clarify that implementations can use stable prefixes once an MSC has merged (#3179)
Fixes #3146.

This PR changes the Matrix Spec Proposals page to clarify that implementations **do not** need to wait until a spec release to use stable prefixes, but that they can do so after the corresponding MSC has been merged. The justification is that once an MSC has been merged, it's fairly guaranteed that it will land in the spec. Yet it will take time for the spec release process to run its course, and we shouldn't make implementations wait for that.

The exception to this is if implementating a feature in a backwards-compatible way requires a new spec version to indicate to clients/servers that a feature has been added/changed. This situation is rare though, and most implementations won't fall into this category.
3 years ago
Andrew Morgan 5d0d5a3981 Clarify what happens when a concern is raised during FCP (#3180)
It wasn't entirely clear what should happen to the FCP timer (and state) when a concern is raised during FCP. After some discussion, we agreed that when a concern is raised:

1. FCP will continue to not conclude until at least 5 days have passed, but once those 5 days are up it *still* won't conclude until all concerns raised during FCP are resolved.
2. If a concern warrants a large enough change in the document, then the Spec Core Team may consider cancelling FCP and restarting the timer in order for people to have some time to think about and review the new changes.
3 years ago
Will 643cdd19c8 Support rendering of proposal tables 3 years ago
Will 68370677ef
Use italics instead of code formatting 4 years ago
Will 79036a34cc
Update proposals document 4 years ago
Will 52745160f3
Use GFM table syntax instead of raw HTML 4 years ago
Will 6c6bd57ebf
Fix ASCII diagrams 4 years ago
Will 74adbfc1ec
Remove 'Table of Contents' 4 years ago
Will 9d4803c8af
Remove duplicate titles 4 years ago
Will c924b3246f
Add page content as raw Pandoc output 4 years ago
Will ebc6db233b
Add empty page placeholders 4 years ago