From 8440179ecfc5ce9d052fc3c8cfbca6256da0e4ad Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Thu, 17 May 2018 18:21:39 +0100 Subject: [PATCH] clarify shepherds and clarify 'greater benefit' as per https://github.com/matrix-org/matrix-doc/pull/1240#discussion_r188459957 --- specification/proposals_intro.rst | 41 ++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 47393fa6..ce577337 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -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