16 Commits (d5c56a4f1765333dc31dcdc66adb913c28d65a7c)

Author	SHA1	Message	Date
Hubert Chathi	0b43b5a343	Add some clarifications around implementation requirements for MSCs (#1718) ... * clarification around implementation requirement, and mention new label * add changelog * fix typo * Fix typos Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --------- Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>	8 months ago
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