 | #matrix-spec-process:matrix.org | 100 Members |
| For meta-discussion about the MSC proposal process | https://matrix.org/blog/2018/06/20/towards-open-governance-for-matrix-org/ | https://github.com/matrix-org/matrix-doc/issues/1318 | 42 Servers |
| #matrix-spec-process:matrix.org | 100 Members |
| For meta-discussion about the MSC proposal process | https://matrix.org/blog/2018/06/20/towards-open-governance-for-matrix-org/ | https://github.com/matrix-org/matrix-doc/issues/1318 | 42 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Apr 2021 | ||
 TravisR | I would suggest watching https://www.youtube.com/watch?v=SFkZz60RRfc&ab_channel=Matrixdotorg for an explanation of how we intend the MSC process to work | 21:25:09 |
| TravisR | In that talk, M goes into detail about how and why we don't require super formal documents | 21:25:43 |
| TravisR | the short answer is basically because we don't believe that documentation should be the barrier to an idea: we do start to nitpick the MSCs as they get closer to the FCP ("what is a string"), but until that point we mostly leave it to say whatever it wants. | 21:33:15 |
 Erkin Alp | In reply to @travis:t2l.iothe solution for that would be using a better vcs (meaning no more github) | 21:46:37 |
| TravisR | I feel I'm missing a few steps... how? | 21:48:36 |
 uhoreg | For some MSCs, writing the spec PR often consists of a bunch of copying-and-pasting from the MSC into various sections of the spec, though it will usually need some degree of massaging so that it fits in better. But we don't want to require people to agonize over the exact wording of things in order to propose an idea. Or to turn the MSC approval process into a nitpicking-fest on writing style. Or require people to dig into exactly how our repository is structured and OMG why do I use swagger for this thing, but not for this other thing that looks exactly the same. | 21:49:56 |
| TravisR | (or why our examples are jsonyamljson) | 21:50:53 |
| Erkin Alp | In reply to @travis:t2l.ioi mean patch theory based VCSs like darcs, rather than file snapshot based ones like git | 21:54:41 |
| TravisR | it sounds like in that case we'd be overly tying the process to the VCS which runs the spec, which isn't something we want to do | 21:55:40 |
| uhoreg | patch theory won't be able to solve every conflict | 21:55:58 |
| Erkin Alp | you'd have far fewer but harder to resolve confilicts than you'd get in the same changeset in a snapshot based one | 21:57:40 |
| 1 May 2021 | ||
| TravisR | In reply to @madlittlemods:matrix.orgftr, these are some MSCs which followed a legacy process which need implementation, if you're interested in pursuing them 😇 https://github.com/matrix-org/matrix-doc/issues?q=label%3Afinished-final-comment-period | 01:37:17 |
| TravisR | if they don't list unstable prefixes, it should be safe to assume org.matrix.msc#### is okay for now. | 01:38:01 |
| TravisR | and because they are all in room versions, you should only need to namespace the room version itself (as it effectively acts as a type in these scenarios) | 01:38:37 |
| TravisR | or bundle them all into a my.happy.little.room.version version instead | 01:39:09 |
| 2 May 2021 | ||
 Sorunome changed their profile picture. | 09:10:01 | |
| Erkin Alp | In reply to @hubert:uhoreg.caok, got it; but what if sb decides to offer it anyway? is that acceptable? | 21:13:16 |
| Erkin Alp | if it is, i will offer diffs for limits api series by myself, because i hava pretty much solidified the design to that point | 21:15:49 |
| Erkin Alp | * if it is, i will offer diffs for limits api series by myself, because i have pretty much solidified the design to that point | 21:16:03 |
| TravisR | if the MSC includes spec diffs, we reject the MSC until those diffs are removed. | 21:16:43 |
| TravisR | it causes so much noise in the proposal process that we deliberately do not accept it | 21:17:15 |
| TravisR | as for the limits API: it's not near a spec writing stage at the moment. You still need review from the SCT and implementation proof before it is worth writing any amount of spec | 21:18:25 |
| 3 May 2021 | ||
| Erkin Alp | Redacted or Malformed Event | 02:59:11 |
| 6 May 2021 | ||
 [Jonathan] joined the room. | 21:10:14 | |
| [Jonathan] | Relaying the question I asked in the SCT office; When does the SCT definitively mark a proposal “stable” in the sense of “it is in the spec, matrix consumers and producers must/could properly implement/use it with stable identifiers”? | 21:11:51 |
| [Jonathan] | I can see three points;
| 21:12:38 |
| TravisR | there's a 3 part answer to that:
As far as the spec is concerned, an MSC is either "accepted", "merged", or closed/postponed. When a | 21:15:56 |
| TravisR | Some MSCs will not be able to switch to stable ahead of the spec release due to dependence on the spec version, but those MSCs are rare. | 21:16:20 |
| [Jonathan] | So, in other words; “When a MSC is accepted, it’s stable enough to be used by implementations, but unstable prefixes can only exist for until two months after the first spec release in which the MSCs official wording exists, but, there are exceptions.”? | 21:20:01 |
| [Jonathan] | * So, in other words; “When a MSC is accepted, it’s stable enough to be used by implementations, but unstable prefixes can only exist for until two months after the first spec release in which the MSCs official wording exists, but, exceptions could exist.”? | 21:20:28 |