From 9eba63b816f2d91e355bff171eb251b7a650582e Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Wed, 13 Jul 2016 12:19:42 +0100 Subject: [PATCH] CONTRIBUTING PR feedback * Make it clear that we won't do spec changes unless backed up by working implementations. * Try to pin down when we expect a proposal doc a bit better --- CONTRIBUTING.rst | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index e775c2185..1cbba00b2 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -36,9 +36,13 @@ workflow: `_ is a good place to reach the core team and others who may be interested in your proposal. -3. Prototype the changes in servers and clients. Refer to the CONTRIBUTING files +3. Implement the changes in servers and clients. Refer to the CONTRIBUTING files of the relevant projects for details of how best to do this. + In general we will be unable to publish specification updates until the + reference server implements them, and they have been proven by a working + client implementation. + 4. Iterate steps 1-3 as necessary. 5. Write the specification for the change, and create a `pull request`_ for @@ -56,9 +60,15 @@ put new requirements on servers. This category of changes includes the following: * changes to supporting documentation + * changes to the scripts used to generate the specification + * clarifications to the specification which do not change the behaviour of - Matrix servers. + Matrix servers or clients in a way which might introduce compatibility + problems for existing deployments. For example, recommendations for UI + behaviour do not require a proposal document. On the other hand, changes to + event contents would be best discussed in a proposal document even though no + changes would be necessary to server implementations. For such changes, please do just open a `pull request`_.