Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-27 08:23:42 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Etiquette -> guiding principles

Browse source
This commit is contained in:
Andrew Morgan 2018-10-20 23:35:33 +02:00
parent ea21e31a0c
commit f00be6b0d8
2 changed files with 41 additions and 43 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

41
specification/proposal_etiquette.rst
View file

@ -1,41 +0,0 @@
.. title:: Proposal Etiquette
Proposal Etiquette
------------------
Proposals **must** act to the greater benefit of the entire Matrix ecosystem,
rather than benefiting or privileging any single player or subset of players -
and must not contain any patent encumbered intellectual property. Members of the Core Team pledge to act as
a neutral custodian for Matrix on behalf of the whole ecosystem.
For clarity: the Matrix ecosystem is anyone who uses the Matrix protocol. That
includes client users, server admins, client developers, bot developers,
bridge and application service developers, users and admins who are indirectly using Matrix via
3rd party networks which happen to be bridged, server developers, room
moderators and admins, companies/projects building products or services on
Matrix, spec contributors, translators, and those who created it in
the first place.
"Greater benefit" could include maximising:
* the number of end-users reachable on the open Matrix network
* the number of regular users on the Matrix network (e.g. 30-day retained
federated users)
* the number of online servers in the open federation
* the number of developers building on Matrix
* the number of independent implementations which use Matrix
* the quality and utility of the Matrix spec
In addition, proposal authors are expected to uphold the following values in
their proposed changes to the Matrix protocol:
* Supporting the whole long-term ecosystem rather than individual stakeholder gain
* Openness rather than proprietariness
* Collaboration rather than competition
* Accessibility rather than elitism
* Transparency rather than stealth
* Empathy rather than contrariness
* Pragmatism rather than perfection
* Proof rather than conjecture
Return to the `proposals page <proposals.html>`_.

43
specification/proposals_intro.rst
View file

@ -24,6 +24,47 @@ towards the benefit of everyone. As a majority, team members have the ability
to change the state of a proposal, and individually have the final say in to change the state of a proposal, and individually have the final say in
proposal discussion. proposal discussion.
Guiding Principles
------------------
Proposals **must** act to the greater benefit of the entire Matrix ecosystem,
rather than benefiting or privileging any single player or subset of players -
and must not contain any patent encumbered intellectual property. Members of the Core Team pledge to act as
a neutral custodian for Matrix on behalf of the whole ecosystem.
For clarity: the Matrix ecosystem is anyone who uses the Matrix protocol. That
includes client users, server admins, client developers, bot developers,
bridge and application service developers, users and admins who are indirectly using Matrix via
3rd party networks which happen to be bridged, server developers, room
moderators and admins, companies/projects building products or services on
Matrix, spec contributors, translators, and those who created it in
the first place.
"Greater benefit" could include maximising:
* the number of end-users reachable on the open Matrix network
* the number of regular users on the Matrix network (e.g. 30-day retained
federated users)
* the number of online servers in the open federation
* the number of developers building on Matrix
* the number of independent implementations which use Matrix
* the quality and utility of the Matrix spec
In addition, proposal authors are expected to uphold the following values in
their proposed changes to the Matrix protocol:
* Supporting the whole long-term ecosystem rather than individual stakeholder gain
* Openness rather than proprietariness
* Collaboration rather than competition
* Accessibility rather than elitism
* Transparency rather than stealth
* Empathy rather than contrariness
* Pragmatism rather than perfection
* Proof rather than conjecture
Process
-------
The process for submitting a Matrix Spec Change (MSC) Proposal in detail is as The process for submitting a Matrix Spec Change (MSC) Proposal in detail is as
follows: follows:
@ -118,8 +159,6 @@ follows:
you've contributed to the Matrix protocol for the benefit of users and you've contributed to the Matrix protocol for the benefit of users and
developers alike :) developers alike :)
Please also read the separate document on `proposal etiquette <proposal_etiquette.html>`_.
The process for handling proposals is shown visually in the following diagram. The process for handling proposals is shown visually in the following diagram.
Note that the lifetime of a proposal is tracked through the corresponding Note that the lifetime of a proposal is tracked through the corresponding
labels for each stage on the `matrix-doc labels for each stage on the `matrix-doc