Commit graph

16 commits

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>
2024-03-13 11:28:30 -04:00
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.
2022-05-03 13:45:44 +01:00
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.
2022-04-20 16:36:14 +01:00
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.
2022-04-19 12:53:20 +01:00
Matthew Hodgson
c151353956 s/master/main/g otherwise we link to stale content 2022-01-25 23:40:32 +00:00
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.
2021-08-27 19:17:14 +01:00
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.
2021-08-27 19:17:14 +01:00
Will
643cdd19c8 Support rendering of proposal tables 2021-08-27 19:16:42 +01:00
Will
68370677ef
Use italics instead of code formatting 2021-01-28 16:21:16 -08:00
Will
79036a34cc
Update proposals document 2021-01-21 20:41:19 -08:00
Will
52745160f3
Use GFM table syntax instead of raw HTML 2021-01-21 17:08:08 -08:00
Will
6c6bd57ebf
Fix ASCII diagrams 2021-01-19 16:41:28 -08:00
Will
74adbfc1ec
Remove 'Table of Contents' 2021-01-19 15:32:30 -08:00
Will
9d4803c8af
Remove duplicate titles 2021-01-19 15:30:52 -08:00
Will
c924b3246f
Add page content as raw Pandoc output 2021-01-19 15:14:52 -08:00
Will
ebc6db233b
Add empty page placeholders 2021-01-19 14:15:46 -08:00