From 93681458d691fc978181dd4839e9217e563eb0a1 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Mon, 14 May 2018 22:13:28 +0100 Subject: [PATCH] more tweaks --- specification/proposals_intro.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 6bdc653a..e1024e57 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -12,11 +12,11 @@ The process for submitting a Matrix Spec Change (MSC) Proposal is as follows: - We also don't jump straight to PRing against the spec itself, as it's much faster to iterate on a proposal in freeform document form than in the terse and formal structure of the spec. - In the proposal, please clearly state the problem being solved, and the possible solutions being proposed for solving it and their trade-offs. - Proposal documents are intended to be as lightweight and flexible as the author desires; there is no formal template; the intention is to iterate as quickly as possible to get to a good design. -- make a new issue at https://github.com/matrix-org/matrix-doc/issues, whose description should list the metadata as per below. +- make a new issue at https://github.com/matrix-org/matrix-doc/issues (or modify an existing one), whose description should list the metadata as per below. - Gather feedback as widely as possible from the community and core team on the proposal. - The aim is to get maximum consensus on the trade-offs chosen to get an optimal solution. - - Iterating on the proposal and getting consensus can sometimes be time-consuming; an impartial 'shepherd' can be assigned to help guide the proposal through this process. -- Once the proposal has consensus and passed review, you **must** show an implementation to prove that it works well in practice, before before a spec PR will be accepted. Iterate on the proposal if needed. + - Iterating on the proposal and gathering consensus can sometimes be time-consuming; an impartial 'shepherd' can be assigned to help guide the proposal through this process. +- Once the proposal has sufficient consensus and passed review, you **must** show an implementation to prove that it works well in practice, before before a spec PR will be accepted. Iterate on the proposal if needed. - Finally, please make a new spec PR which includes the proposed changes against https://github.com/matrix-org/matrix-doc/tree/master/specification. This will then be reviewed and hopefully merged! The process for handling proposals is described in the following diagram. Note that the lifetime of a proposal is tracked through the corresponding labels for each stage in the `matrix-doc issue tracker `_.