archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

incorporating delph & vdh reviews

Browse Source
matthew/msc1779
Matthew Hodgson 7 years ago
parent 80b9c83cce
commit 3b86fa0e3c
2 changed files with 72 additions and 50 deletions
Show Stats Download Patch File Download Diff File

100
proposals/1779-open-governance.md
Unescape Escape View File

@ -69,9 +69,9 @@ We believe:
* People should have full control over their own communication. * People should have full control over their own communication.
* People should not be locked into centralised communication silos, but free to * People should not be locked into centralised communication silos, but instead
pick who they choose to host their communication without limiting who they be free to pick who they choose to host their communication without limiting
can reach. who they can reach.
* The ability to converse securely and privately is a basic human right. * The ability to converse securely and privately is a basic human right.
@ -80,9 +80,9 @@ We believe:
### Mission ### Mission
The Matrix.org Foundation exists to act as a neutral custodian for Matrix and The Matrix.org Foundation exists to act as a neutral custodian for Matrix and to
nurture it as efficiently as possible as a single unfragmented standard, for the nurture it as efficiently as possible as a single unfragmented standard, for the
greater benefit of the whole ecosystem; not benefiting or privileging any single greater benefit of the whole ecosystem, not benefiting or privileging any single
player or subset of players. player or subset of players.
For clarity: the Matrix ecosystem is defined as anyone who uses the Matrix For clarity: the Matrix ecosystem is defined as anyone who uses the Matrix
@ -185,8 +185,8 @@ fall back to interoperating correctly with the rest of the ecosystem.
The Spec Core Team itself will be made up of roughly 8 members + 1 project lead. The Spec Core Team itself will be made up of roughly 8 members + 1 project lead.
Roughly half the members are expected to be from the historical core team Roughly half the members are expected to be from the historical core team
(similar to Rust). The team must have 5 members to be quorate, with the aim of (similar to Rust). The team must have 5 members to be able to function, with
generally having between 7 and 9 members. the aim of generally having between 7 and 9 members.
In future we may also have sub-teams (like Rust - e.g. CS/AS/Push API; SS API; In future we may also have sub-teams (like Rust - e.g. CS/AS/Push API; SS API;
IS API; Crypto), but as a starting point we are beginning with a single core IS API; Crypto), but as a starting point we are beginning with a single core
@ -221,13 +221,14 @@ of the team and the Guardians on doing so.
New additions to the team require 100% consent from the current team members. New additions to the team require 100% consent from the current team members.
Membership has to be formally proposed by someone already on the Spec Core Team. Membership has to be formally proposed by someone already on the Spec Core Team.
Members can be removed from the team if >= 75% of the team agrees they are no Members can be removed from the team if 75% of the current members approves and
longer following the goals and guiding principles of the project. (The 75% is agrees they are no longer following the goals and guiding principles of the
measured of the whole team, including the member in question) project. (The 75% is measured of the whole team, including the member in
question).
Guardians act as a backstop, and can appoint or remove Spec Core Team members Guardians act as a safety net, and can appoint or remove Spec Core Team members
(requiring a 75% consensus threshold between the Guardians) if the Spec Core (requiring approval by 75% of the current Guardians) if the Spec Core Team is
Team is unable to function or is failing to align with the Foundation's mission. unable to function or is failing to align with the Foundation's mission.
It's suggested that one of the Spec Core Team members should also be a Guardian, It's suggested that one of the Spec Core Team members should also be a Guardian,
to facilitate information exchange between the Guardians and the Spec Core Team, to facilitate information exchange between the Guardians and the Spec Core Team,
@ -236,12 +237,14 @@ and to represent the technical angle of the project to the other Guardians.
The project lead role acts to coordinate the team and to help steer the team to The project lead role acts to coordinate the team and to help steer the team to
consensus in the event of failing to get agreement on a Matrix Spec Change. consensus in the event of failing to get agreement on a Matrix Spec Change.
Every 12 months, a vote of confidence is held in the project lead, requiring the Every 12 months, a vote of confidence is held in the project lead, requiring the
confidence of 75% of the team for the lead to be renewed. There is no maximum approval of 75% of the current Spec Core Team members for the lead to be
term for the project lead. The lead may be removed by the core team at any renewed. There is no maximum term for the project lead. The lead may be
point (with 75% majority), and may resign the role at any point (notifying the removed by the core team at any point (requiring 75% approval of current
team and the Guardians). The lead automatically resigns the role if they resign members), and may resign the role at any point (notifying the team and the
from the Spec Core Team. Resignation automatically triggers selection of a new Guardians). The lead automatically resigns the role if they resign from the
lead, who must be selected from the existing Spec Core Team. Spec Core Team. Resignation automatically triggers selection of a new lead, who
must be selected from the existing Spec Core Team with 75% approval from current
members within 14 days.
It is vital that the core spec team has strong domain expertise covering all It is vital that the core spec team has strong domain expertise covering all
different domains of the spec (e.g. we don't want to end up with a core spec different domains of the spec (e.g. we don't want to end up with a core spec
@ -259,21 +262,24 @@ The initial Spec Core Team (and their domain areas) is:
* Alexey Rusakov (Clients on behalf of Community) * Alexey Rusakov (Clients on behalf of Community)
* TBD * TBD
MSCs require >= 75% approval from the Spec Core Team to proceed to Final Comment MSCs require approval by 75% of the current members of the Spec Core Team to
Period (see https://matrix.org/docs/spec/proposals for the rest of the MSC proceed to Final Comment Period (see https://matrix.org/docs/spec/proposals for
process). the rest of the MSC process).
Even though a threshold of only 75% is required for approval, the Spec Core Team Even though a threshold of only 75% is required for approval, the Spec Core Team
is expected to seek consensus on MSCs. is expected to seek consensus on MSCs.
The above governance process for the Spec Core Team is considered as part of the The above governance process for the Spec Core Team is considered as part of the
spec and is updated using the Matrix Spec Change process. However, changes to spec and is updated using the Matrix Spec Change process. However, changes to
the governance process also require a 75% positive approval from the Guardians the governance process also require approval by 75% of the current Guardians
(acting as a formal decision of the Foundation's Directors), in order to ensure (acting as a formal decision of the Foundation's Directors), in order to ensure
changes are aligned with the Foundation's mission. For avoidance of doubt, Spec changes are aligned with the Foundation's mission. For avoidance of doubt, Spec
Core Team votes and Guardians' votes are distinct and a person having both hats Core Team votes and Guardians' votes are distinct and a person having both hats
has to vote independently on both forums with the respective hat on. has to vote independently on both forums with the respective hat on.
Spec Core Team decisions (e.g. appointing/removing members and lead)
should be published openly and transparently for the public.
## The Guardians ## The Guardians
*This section will be used as the basis for the legal responsibilities of *This section will be used as the basis for the legal responsibilities of
@ -285,16 +291,23 @@ is following its guiding principles, and provide a safety mechanism if the
structure of the Spec Core Team runs into trouble. structure of the Spec Core Team runs into trouble.
In practice, this means that: In practice, this means that:
* Guardians must approve changes to the Spec Core Team.
* Guardians are responsible for ensuring the Spec Core Team continues to
function, and have the power to appoint/dismiss members of the spec core team
(with the agreement of 75% of the Guardians) to address issues with the Spec
Core Team.
* Guardians must keep each other honest, providing a ‘checks and balances’. * Guardians must keep each other honest, providing a ‘checks and balances’.
mechanism between each other to ensure that all Guardians and the Spec Core mechanism between each other to ensure that all Guardians and the Spec Core
Team act in the best interests of the protocol and ecosystem. Team act in the best interests of the protocol and ecosystem.
* Guardians may appoint/dismiss members of the Spec Core Team who are in serious * Guardians may dismiss members of the Spec Core Team who are in serious
breach of the guiding principles. This overrides the unanimous consent breach of the guiding principles.
requirement for the Spec Core Team when appointing new members. * Guardians may appoint members of the Spec Core Team to break deadlocks in the
unanimous consent requirement for the Spec Core Team when appointing new
members.
* Guardians may also override deadlocks when appointing a Spec Core Team leader * Guardians may also override deadlocks when appointing a Spec Core Team leader
(with a >= 75% majority). (with approval of 75% of the current Guardians).
* Guardians must approve changes to the Guiding Principles (above) * Guardians must approve changes to the above Guiding Principles (with approval
of 75% of the current Guardians)
* Guardians are responsible for approving use of the Foundation's assets * Guardians are responsible for approving use of the Foundation's assets
(e.g. redistributing donations). (e.g. redistributing donations).
* In future, Guardians may also be responsible for ensuring staff are hired by * In future, Guardians may also be responsible for ensuring staff are hired by
@ -303,8 +316,14 @@ In practice, this means that:
* As well as the Spec Core Team committee, they may also oversee committees for * As well as the Spec Core Team committee, they may also oversee committees for
other areas such as marketing Matrix.org, registering custom event types, other areas such as marketing Matrix.org, registering custom event types,
or "Made for Matrix" certification. or "Made for Matrix" certification.
* It's likely a subset of Guardians will be hands-on for day-to-day * Guardians are responsible for choosing if, when and how staff are located by
administrative purposes, whilst the others act to keep them in balance. the Foundation to fill administrative and other functions required to
facilitate the Foundations' mission.
* Guardians are responsible for choosing if and when additional committees are
formed, and to oversee those committees.
* Guardians are not required to be involved on a day-to-day basis, however
those not taking a hands on approach are required to monitor to ensure a
suitable balance is kept by those that do.
Guardians are chosen typically to be independent of the commercial Matrix Guardians are chosen typically to be independent of the commercial Matrix
ecosystem (and especially independent from New Vector), and may even not be ecosystem (and especially independent from New Vector), and may even not be
@ -313,18 +332,18 @@ the mission of the project, and respected and trusted by the wider community to
uphold the guiding principles of the Foundation and keep the other Guardians uphold the guiding principles of the Foundation and keep the other Guardians
honest. honest.
Guardians are responsible for maintaining and updating the Guiding Guardians are responsible for maintaining and updating the Guiding Principles
Principles and Articles of Association of the Foundation if/when and Articles of Association of the Foundation if/when necessary. Changes to the
necessary. Changes to the Guiding Principles require a 75% majority from the Guiding Principles require approval from 75% of the current Guardians and are
Guardians and are passed as a 'special resolution' of the board. passed as a 'special resolution' of the board.
New Guardians may be appointed with a 75% majority by the board. New Guardians may be appointed with approval from 75% of the current Guardians.
Guardians may resign at any time, with notification to the board. Guardians may resign at any time, with notification to the board.
Guardians may be removed due to serious breach of the guiding principles with a Guardians may be removed due to serious breach of the guiding principles with
75% majority of the other Guardians, or if absent from 3 consecutive board approval by 75% of the other current Guardians, or if absent from 3 consecutive
meetings, or if they are legally disqualified from acting as a Director. board meetings, or if they are legally disqualified from acting as a Director.
We aim to recruit roughly 5 Guardians. The initial Guardians are: We aim to recruit roughly 5 Guardians. The initial Guardians are:
@ -340,6 +359,9 @@ Foundation relative to Matthew & Amandine’s day jobs at New Vector.
Guardians must arrange their own funding for their time. Guardians must arrange their own funding for their time.
Guardian decisions (e.g. appointing/removing guardians; changes to the spec core
team; etc) should be published openly and transparently for the public.
## The Code Core Team (aka The Core Team) ## The Code Core Team (aka The Core Team)
The "Core Team" (or the "Code Core Team", to disambiguate from the Spec Core The "Core Team" (or the "Code Core Team", to disambiguate from the Spec Core

22
specification/proposals_intro.rst
Unescape Escape View File

@ -19,10 +19,10 @@ proposal being accepted, then actually having your ideas implemented as
committed changes to the `Specification repository committed changes to the `Specification repository
<https://github.com/matrix-org/matrix-doc>`_. <https://github.com/matrix-org/matrix-doc>`_.
Meet the `members of the Core Team Meet the `members of the Spec Core Team
<https://github.com/orgs/matrix-org/teams/spec-core-team/members>`_, a group of <https://github.com/orgs/matrix-org/teams/spec-core-team/members>`_, a group of
individuals tasked with ensuring the spec process is as smooth and painless as individuals tasked with ensuring the spec process is as smooth and painless as
possible. Members of the Core Team will do their best to participate in possible. Members of the Spec Core Team will do their best to participate in
discussion, summarise when things become long-winded, and generally try to act discussion, summarise when things become long-winded, and generally try to act
towards the benefit of everyone. As a majority, team members have the ability 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
@ -74,7 +74,7 @@ their proposed changes to the Matrix protocol:
* Pragmatism rather than perfection * Pragmatism rather than perfection
* Proof rather than conjecture * Proof rather than conjecture
Please see [MSC1779](https://github.com/matrix-org/matrix-doc/pull/1779) Please see [MSC1779](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1779/proposals/1779-open-governance.md)
for full details of the project's Guiding Principles. for full details of the project's Guiding Principles.
Technical notes Technical notes
@ -213,25 +213,25 @@ follows:
viewpoints and get consensus, but this can sometimes be time-consuming (or 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 the author may be biased), in which case an impartial 'shepherd' can be
assigned to help guide the proposal through this process instead. A shepherd is assigned to help guide the proposal through this process instead. A shepherd is
typically a neutral party from the Core Team or an experienced member of typically a neutral party from the Spec Core Team or an experienced member of
the community. There is no formal process for assignment. Simply ask for a the community. There is no formal process for assignment. Simply ask for a
shepherd to help get your proposal through and one will be assigned based shepherd to help get your proposal through and one will be assigned based
on availability. Having a shepherd is not a requirement for proposal on availability. Having a shepherd is not a requirement for proposal
acceptance. acceptance.
- Members of the Core Team and community will review and discuss the PR in the - Members of the Spec Core Team and community will review and discuss the PR in the
comments and in relevant rooms on Matrix. Discussion outside of GitHub should comments and in relevant rooms on Matrix. Discussion outside of GitHub should
be summarised in a comment on the PR. be summarised in a comment on the PR.
- When a member of the Core Team believes that no new discussion points are - When a member of the Spec Core Team believes that no new discussion points are
being made, they will propose a motion for a final comment period (FCP), being made, they will propose a motion for a final comment period (FCP),
along with a *disposition* of either merge, close or postpone. This FCP is along with a *disposition* of either merge, close or postpone. This FCP is
provided to allow a short period of time for any invested party to provide a provided to allow a short period of time for any invested party to provide a
final objection before a major decision is made. If sufficient reasoning is final objection before a major decision is made. If sufficient reasoning is
given, an FCP can be cancelled. It is often preceded by a comment summarising given, an FCP can be cancelled. It is often preceded by a comment summarising
the current state of the discussion, along with reasoning for its occurrence. the current state of the discussion, along with reasoning for its occurrence.
- A concern can be raised by a Core Team member at any time, which will block - A concern can be raised by a Spec Core Team member at any time, which will block
an FCP from beginning. An FCP will only begin when a **majority** of core an FCP from beginning. An FCP will only begin when 75% of the members of the
team members agree on its outcome, and all existing concerns have been Spec Core Team team agree on its outcome, and all existing concerns have been
resolved. resolved.
- The FCP will then begin and last for 5 days, giving anyone else some time to - The FCP will then begin and last for 5 days, giving anyone else some time to
speak up before it concludes. On its conclusion, the disposition of the FCP speak up before it concludes. On its conclusion, the disposition of the FCP
@ -321,7 +321,7 @@ Lifetime States
Name GitHub Label Description Name GitHub Label Description
=============================== ============================= ==================================== =============================== ============================= ====================================
Proposal Drafting and Feedback N/A A proposal document which is still work-in-progress but is being shared to incorporate feedback Proposal Drafting and Feedback N/A A proposal document which is still work-in-progress but is being shared to incorporate feedback
Proposal In Review proposal-in-review A proposal document which is now ready and waiting for review by the Core Team and community Proposal In Review proposal-in-review A proposal document which is now ready and waiting for review by the Spec Core Team and community
Proposed Final Comment Period proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period Proposed Final Comment Period proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period
Final Comment Period final-comment-period A proposal document which has reached final comment period either for merge, closure or postponement Final Comment Period final-comment-period A proposal document which has reached final comment period either for merge, closure or postponement
Final Commment Period Complete finished-final-comment-period The final comment period has been completed. Waiting for a demonstration implementation Final Commment Period Complete finished-final-comment-period The final comment period has been completed. Waiting for a demonstration implementation
@ -342,7 +342,7 @@ pull request trackers of the `matrix-doc
<https://github.com/matrix-org/matrix-doc>`_ repo. <https://github.com/matrix-org/matrix-doc>`_ repo.
We use labels and some metadata in MSC PR descriptions to generate this page. We use labels and some metadata in MSC PR descriptions to generate this page.
Labels are assigned by the Core Team whilst triaging the proposals based on those Labels are assigned by the Spec Core Team whilst triaging the proposals based on those
which exist in the `matrix-doc <https://github.com/matrix-org/matrix-doc>`_ which exist in the `matrix-doc <https://github.com/matrix-org/matrix-doc>`_
repo already. repo already.

Write Preview
Loading…
Cancel
Save