Update the README with details on the Matrix spec process + unstable prefixes #3891
Conversation
In case you somehow missed it.
| The Spec Core Team will notice this and apply various labels/status tracking to | ||
| your MSC, which will announce it to the wider world. |
There was a problem hiding this comment.
will they? it's certainly not a thing I do 😳
There was a problem hiding this comment.
I think this is currently always done by Travis 😇
There was a problem hiding this comment.
This is supposed to be done by the SCT. We should be sharing responsibility on this, too.
There was a problem hiding this comment.
can we automate it? what labels are we talking about here?
There was a problem hiding this comment.
proposal can be automated if we see a file land in the proposals/ directory. We also need to add one of:
kind:corekind:featurekind:maintenance
which is up to the SCT's discretion and depends on the proposal's subject matter.
Additionally needs-implementation; we can probably add this automatically too. In the small cases an implementation is not necessary, someone will complain and a human will review and remove it.
And then ideally one or more of:
client-serverintegrationspushs2swidgets
etc. for different parts of the spec. Could potentially be done later by a human too, but having no labels is currently a good prompt to add these.
There was a problem hiding this comment.
file land in the proposals/ directory.
We have to be careful to ensure that updates to existing proposals don't trigger this, fwiw. We should be checking the MSC number against the file(s) in the diff.
We can add needs-implementation automatically. The process for getting that removed is to go to the SCT office specifically and ask for it - pings on github are unreliable for this case.
In future there's also going to be other planning considerations for every inbound MSC, so while we can automate some labels, there's still going to be a reason for a human to visit and make decisions: deciding on some labels is reasonable here. The automation could/should throw the MSC into an "inbound" queue for this, though.
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
|
||
| Some tips for MSC writing: | ||
|
|
||
| * Please wrap your lines to 80 characters maximum (some small leeway is OK). |
There was a problem hiding this comment.
Contradicts instructions in the specification repository
This PR serves to distill the text under https://spec.matrix.org/proposals/ into something a little more approachable. The text on that page is tersely written on purpose, but may not be the easiest introduction to spec writing. These words, presented in somewhere easy to find (this repository's readme) aims to fill that gap. It also tries to describe some common edge cases in the process in a candid manner.
Much of this text was adapted from words originally written by @erikjohnston. It has been updated and expanded upon here.
This PR does not require a changelog entry.