wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

CONTRIBUTING PR feedback

Browse source 
* 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
This commit is contained in:
Richard van der Hoff 2016-07-13 12:19:42 +01:00
parent 6cfc025bb8
commit 9eba63b816
1 changed files with 12 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

14
CONTRIBUTING.rst
View file

@ -36,9 +36,13 @@ workflow:
<http://matrix.to/#/#matrix-dev:matrix.org>`_ is a good place to reach the <http://matrix.to/#/#matrix-dev:matrix.org>`_ is a good place to reach the
core team and others who may be interested in your proposal. 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. 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. 4. Iterate steps 1-3 as necessary.
5. Write the specification for the change, and create a `pull request`_ for 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: following:
* changes to supporting documentation * changes to supporting documentation
* changes to the scripts used to generate the specification * changes to the scripts used to generate the specification
* clarifications to the specification which do not change the behaviour of * 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`_. For such changes, please do just open a `pull request`_.