clarify shepherds and clarify 'greater benefit'

as per https://github.com/matrix-org/matrix-doc/pull/1240#discussion_r188459957
pull/977/head
Matthew Hodgson 7 years ago
parent 4d3c4225b2
commit 8440179ecf

@ -45,9 +45,14 @@ The process for submitting a Matrix Spec Change (MSC) Proposal is as follows:
trying to run matrix apps (clients & servers);
#matrix-architecture:matrix.org is for cross-cutting discussion of
Matrix's architectural design.
- 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.
- The point of the spec proposal process is to be collaborative rather than
competitive, and to try to solve the problem in question with the optimal
set of trade-offs. Ideally the author would neutrally gather the various
viewpoints and get consensus, but this can sometimes be time-consuming (or
the author may be biased), in which case an impartial 'shepherd' can be
assigned to help guide the proposal through this process. A shepherd is
typically a neutral party from the core team or an experienced member of
the community.
- Once the proposal has sufficient consensus and passed review, you **must**
show an implementation to prove that it works well in practice, before a
@ -69,6 +74,36 @@ rather than benefiting or privileging any single player or subset of players
to act as a neutral custodian for Matrix on behalf of the whole ecosystem,
just as it has since Matrix's inception in May 2014.
For clarity: the Matrix ecosystem is anyone who uses the Matrix protocol. That
includes client users, server admins, client developers, bot developers,
bridge and AS 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 the core team 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.
The guiding principles of the overall project are being worked on as part of
the upcoming governance proposal, but could be something like:
* 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
The above directions are intended to be simple and pragmatic rather than
exhaustive, and aim to provide guidelines until we have a formal spec
governance process in place that covers the whole Matrix community. In order

Loading…
Cancel
Save