Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2025-12-30 12:38:38 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge pull request #1779 from matrix-org/matthew/msc1779

Browse source 
MSC1779: Proposal for Open Governance for Matrix.org (v2)
This commit is contained in:
Matthew Hodgson 2019-06-07 19:20:19 +01:00 committed by GitHub
parent 4b6e2cc956 950415c72a
commit 3438ea50a2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 560 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

457
proposals/1779-open-governance.md Normal file
View file

@ -0,0 +1,457 @@
# Proposal for Open Governance of Matrix.org
This whole document is the proposed constitution proposal for Matrix.org, and
will form the basis of the first full Articles of Association (AoA) for [The
Matrix.org Foundation
C.I.C.](https://beta.companieshouse.gov.uk/company/11648710) - a non-profit
legal entity incorporated to act as the neutral guardian of the Matrix
decentralised communication standard on behalf of the whole Matrix community.
See https://matrix.org/blog/2018/10/29/introducing-the-matrix-org-foundation-part-1-of-2/
for more context.
This obsoletes [MSC1318](https://github.com/matrix-org/matrix-doc/issues/1318).
**This MSC is now formalised in the official Rules of the Matrix.org Foundation,
maintained at https://docs.google.com/document/d/1MhqsuIUxPc7Vf_y8D250mKZlLeQS6E39DPY6Azpc2NY**
## Introduction
Historically the core team of Matrix has been paid to work on it by the same
employer (currently New Vector; the startup incorporated to hire the core
team in Aug 2017). Whilst convenient in initially getting Matrix built, we
recognise that this could create a potential conflict of interest between the
core team’s responsibilities to neutrally support the wider Matrix.org ecosystem
versus the need for New Vector to be able to support the team, and it has always
been the plan to set up a completely neutral custodian for the standard once it
had reached sufficient maturity.
This proposal seeks to establish a new open governance process for Matrix.org,
such that once the specification has finally been ‘born’ and reached an initial
‘r0’ release across all APIs, control of Matrix.org can be decoupled from New
Vector and better support contributions from the whole ecosystem.
The concepts here are somewhat inspired by [Rust’s Governance
Model](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md);
a highly regarded solution to a similar problem: an ambitious
open-source project which has been too many years in the making, incubated at
first by a single company (Mozilla Corporation), which also enjoys a very
enthusiastic community!
## Overview
Governance of the project is split into two teams: the Spec Core Team and the
Guardians of the Foundation. In brief:
The Spec Core Team are the technical experts who curate and edit the Matrix
Specification from day to day, and so steer the evolution of the protocol by
having final review over which Matrix Spec Changes (MSCs) are merged into the
core spec.
The Guardians are the legal directors of the non-profit Foundation, and are
responsible for ensuring that the Foundation (and by extension the Spec Core
Team) keeps on mission and neutrally protects the development of Matrix.
Guardians are typically independent of the commercial Matrix ecosystem and may
even not be members of today’s Matrix community, but are deeply aligned with the
mission of the project. Guardians are selected to be respected and trusted by
the wider community to uphold the guiding principles of the Foundation and keep
the other Guardians honest.
In other words; the Spec Core Team builds the spec, and the Guardians provide an
independent backstop to ensure the spec evolves in line with the Foundation's
mission.
## Guiding Principles
The guiding principles define the core philosophy of the project, and will be a
formal part of the final Articles of Association of the Matrix.org Foundation.
### Matrix Manifesto
We believe:
* People should have full control over their own communication.
* People should not be locked into centralised communication silos, but instead
be free to pick who they choose to host their communication without limiting
who they can reach.
* The ability to converse securely and privately is a basic human right.
* Communication should be available to everyone as a free and open,
unencumbered, standard and global network.
### Mission
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
greater benefit of the whole ecosystem, not benefiting or privileging any single
player or subset of players.
For clarity: the Matrix ecosystem is defined as anyone who uses the Matrix
protocol. This includes (non-exhaustively):
* End-users of Matrix clients.
* Matrix client developers and testers.
* Spec developers.
* Server admins.
* Matrix packagers & maintainers.
* Companies building products or services on Matrix.
* Bridge developers.
* Bot developers.
* Widget developers.
* Server developers.
* Matrix room and community moderators.
* End-users who are using Matrix indirectly via bridges.
* External systems which are bridged into Matrix.
* Anyone using Matrix for data communications.
"Greater benefit" is defined as maximising:
* the number of Matrix-native 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 number of bridged end-users reachable on the open Matrix network.
* the signal-to-noise ratio of the content on the open Matrix network (i.e. minimising spam).
* the ability for users to discover content on their terms (empowering them to select what to see and what not to see).
* the quality and utility of the Matrix spec (as defined by ease and ability
with which a developer can implement spec-compliant clients, servers, bots,
bridges, and other integrations without needing to refer to any other
external material).
N.B. that we consider success to be the growth of the open federated network
rather than closed deployments. For example, if WhatsApp adopted Matrix it
wouldn’t be a complete win unless they openly federated with the rest of the
Matrix network.
### Values
As Matrix evolves, it's critical that the Spec Core Team and Guardians are
aligned on the overall philosophy of the project, particularly in more
subjective areas. The values we follow are:
* Supporting the whole long-term ecosystem rather than individual stakeholder gain.
* Openness rather than proprietary lock-in.
* Interoperability rather than fragmentation.
* Cross-platform rather than platform-specific.
* Collaboration rather than competition.
* Accessibility rather than elitism.
* Transparency rather than stealth.
* Empathy rather than contrariness.
* Pragmatism rather than perfection.
* Proof rather than conjecture.
Patent encumbered IP is strictly prohibited from being added to the standard.
Making the specification rely on non-standard/unspecified behaviour of other
systems or actors (such as SaaS services, even open-sourced, not governed by a
standard protocol) shall not be accepted, either.
## The Spec Core Team
The contents and direction of the Matrix Spec is governed by the Spec Core Team;
a set of experts from across the whole Matrix community, representing all
aspects of the Matrix ecosystem. The Spec Core Team acts as a subcommittee of
the Foundation.
Members of the Spec Core Team pledge to act as a neutral custodian for Matrix on
behalf of the whole ecosystem and uphold the Guiding Principles of the project
as outlined above. In particular, they agree to drive the adoption of Matrix as
a single global federation, an open standard unencumbered from any proprietary
IP or software patents, minimising fragmentation (whilst encouraging
experimentation), evolving rapidly, and prioritising the long-term success and
growth of the overall network over individual commercial concerns.
Spec Core Team members need to have significant proven domain experience/skill
and have had clear dedication and commitment to the project and community for >6
months. (In future, once we have subteams a la Rust, folks need to have proven
themselves there first).
Members need to demonstrate ability to work constructively with the rest of the
team; we want participation in the Spec Core Team to be an efficient, pleasant and
productive place, even in the face of inevitable disagreement. We do not want a
toxic culture of bullying or competitive infighting. Folks need to be able to
compromise; we are not building a culture of folks pushing their personal
agendas at the expense of the overall project.
The team should be particularly vigilant against 'trojan horse' additions to the
spec - features which only benefit particular players, or are designed to
somehow cripple or fragment the open protocol and ecosystem in favour of
competitive advantage. Commercial players are of course free to build
proprietary implementations, or use custom event types, or even custom API
extensions (e.g. more efficient network transports) - but implementations must
fall back to interoperating correctly with the rest of the ecosystem.
### Spec Core Team logistics
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
(similar to Rust). The team must have 5 members to be able to function, with
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;
IS API; Crypto), but as a starting point we are beginning with a single core
team in the interests of not over-engineering it and scaling up elastically.
Spec Core Team members need to be able to commit to at least 1 hour a week of
availability to work on the spec and (where relevant) reference implementations.
Members must arrange their own funding for their time.
Responsibilities include:
* Reviewing Matrix Spec Change proposals and Spec PRs.
* Contributing to and reviewing reference implementations of Matrix Spec Change
proposals.
* Shepherding Matrix Spec Changes on behalf of authors where needed.
* Triaging Matrix Spec issues.
* Coordinating reference implementations.
* Ensuring the code of conduct for +matrix:matrix.org community rooms is
maintained and applied.
If members are absent (uncontactable) for more than 8 weeks without prior
agreement, they will be assumed to have left the project.
Spec Core Team members can resign whenever they want, but must notify the rest
of the team and the Guardians on doing so.
New additions to the team must be approved by all current members of the 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 current members approves and
agrees they are no longer following the goals and guiding principles of the
project. (The 75% is measured of the whole team, including the member in
question).
Guardians act as a safety net, and can appoint or remove Spec Core Team members
(requiring approval by 75% of the current Guardians) if the Spec Core Team is
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,
to facilitate information exchange between the Guardians and the Spec Core Team,
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
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
approval of 75% of the current Spec Core Team members for the lead to be
renewed. There is no maximum term for the project lead. The lead may be
removed by the core team at any point (requiring 75% approval of current
members), and may resign the role at any point (notifying the team and the
Guardians). The lead automatically resigns the role if they resign from the
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
different domains of the spec (e.g. we don't want to end up with a core spec
team where nobody has strong experience in cryptography)
The initial Spec Core Team (and their domain areas) is:
* Matthew Hodgson (Lead, Guardian)
* Erik Johnston (Servers)
* Richard van der Hoff (Servers, Cryptography)
* David Baker (Clients, IS API, Push API, Media)
* Hubert Chathi (Cryptography, General)
* Andrew Morgan (Servers, AS API, Spec Process)
* Travis Ralston (Bots and Bridges & AS API, Media, acting with Dimension hat on)
* Alexey Rusakov (Clients on behalf of Community)
* TBD
MSCs require approval by 75% of the current members of the Spec Core Team to
proceed to Final Comment Period (see https://matrix.org/docs/spec/proposals for
the rest of the MSC process).
Even though a threshold of only 75% is required for approval, the Spec Core Team
is expected to seek consensus on MSCs.
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
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
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
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
*This section will be used as the basis for the legal responsibilities of
Directors in the Articles of Association of the Foundation.*
The Guardians form the legal Board of Directors of The Matrix.org Foundation CIC
(Community Interest Company). They are responsible for ensuring the Foundation
is following its guiding principles, and provide a safety mechanism if the
structure of the Spec Core Team runs into trouble.
In practice, this means that:
* 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’.
mechanism between each other to ensure that all Guardians and the Spec Core
Team act in the best interests of the protocol and ecosystem.
* Guardians may dismiss members of the Spec Core Team who are in serious
breach of the guiding principles.
* 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
(with approval of 75% of the current Guardians).
* 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
(e.g. redistributing donations).
* In future, Guardians may also be responsible for ensuring staff are hired by
the Foundation to support administrative functions and other roles required
to facilitate the Foundation's mission.
* 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,
or "Made for Matrix" certification.
* Guardians are responsible for choosing if, when and how staff are located by
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
ecosystem (and especially independent from New Vector), and may even not be
members of today’s Matrix community. However, they should be deeply aligned with
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
honest.
Guardians are responsible for maintaining and updating the Guiding Principles
and Articles of Association of the Foundation if/when necessary. Changes to the
Guiding Principles require approval from 75% of the current Guardians and are
passed as a 'special resolution' of 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 be removed due to serious breach of the guiding principles with
approval by 75% of the other current Guardians, or if absent from 3 consecutive
board meetings, or if they are legally disqualified from acting as a Director.
We aim to recruit roughly 5 Guardians. The initial Guardians are:
* Matthew Hodgson (CEO/CTO, New Vector)
* Amandine Le Pape (COO, New Vector)
* TBA (agreed, needs paperwork)
* TBD
* TBD
The intention is for Matthew & Amandine (the original founders of Matrix) to
form a minority of the Guardians, in order to ensure the neutrality of the
Foundation relative to Matthew & Amandine’s day jobs at New Vector.
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 "Core Team" (or the "Code Core Team", to disambiguate from the Spec Core
Team) is a loose term that describes the set of people with access to commit
code to the public https://github.com/matrix-org repositories, who are either
working on matrix.org's reference implementations or the spec itself. Commit
access is decided by those responsible for the projects in question, much like
any other open source project. Anyone is eligible for commit access if they
have proved themselves a valuable long-term contributor, uphold the guiding
principles and mission of the project and have proved themselves able to
collaborate constructively with the existing core team. Active participation in
the core team is also signified by membership of the +matrix:matrix.org Matrix
community.
Responsibilities include:
* Helping ensure the quality of the projects' code repositories.
* Ensuring all commits are reviewed.
* Ensuring that all projects follow the Matrix spec.
* Helping architect the implementations.
* Contributing code to the implementations.
* Fostering contributions and engaging with contributors constructively in a
way that fosters a healthy and happy community.
* Following the Guiding Principles and promoting them within the community.
Code Core Team members must arrange their own funding for their time.
## Functions of the Foundation
* Independent legal entity which acts as neutral custodian of Matrix.
* Gathers donations.
* Owns the core Matrix IP in an asset lock, which shall be transferred from New Vector:
* Owns the matrix.org domain and branding.
* Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org).
By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it.
* Owns the IP of the website.
* Owns the Matrix.org marketing swag (t-shirts, stickers, exhibition stands etc).
* Responsible for finding someone to run the Matrix.org homeserver (currently New Vector).
* Publishes the spec.
* Responsible for tools and documentation that support the spec.
* Responsible for ensuring reference implementations and test suite exists for the spec.
* Publishes the website (including ensuring This Week In Matrix and similar exist to promote independent projects).
* Manages any future IANA-style allocations for Matrix, such as:
* mx:// URI scheme.
* TCP port 8448.
* .well-known URIs
* Ensures that Matrix promotion is happening (e.g. ensuring that meetups &
events & community activity is supported).
In future:
* Contracts entities to work on Matrix if such contracts help the Foundation to
fulfil its mission and obey the Guiding Principles (e.g. redistributing
donations back to fund development of reference implementations or compliance
kits).
* Manages a "Made for Matrix" certification process? (to confirm that products
are actually compatible with Matrix).
## Timings
The Foundation was incorporated in October 2018 as a UK limited by guarantee
private company, using generic non-profit articles of association combined with
a high-level mission lock aligned with the above:
> 4. The objects of the Foundation are for the benefit of the community as a whole
> to:
> 4.1.1 empower users to control their communication data and have freedom over
> their communications infrastructure by creating, maintaining and promoting
> Matrix as an openly standardised secure decentralised communication protocol and
> network, open to all, and available to the public for no charge;
> 4.1.2 build and develop an appropriate governance model for Matrix through the
> Foundation, in order to drive the adoption of Matrix as a single global
> federation, an open standard unencumbered from any proprietary intellectual
> property and/or software patents, minimising fragmentation (whilst encouraging
> experimentation), maximising speed of development, and prioritising the long-
> term success and growth of the overall network over the commercial concerns of
> an individual person or persons.
The foundation was then converted into a Community Interest Company, formalising
its non-profit status under the approval of the independent [Community Interest
Companies Regulator](https://www.gov.uk/government/organisations/office-of-the-regulator-of-community-interest-companies),
which took effect Jan 2019.
We are currently planning to release r0 of the Matrix Spec at the end of Jan 2019, and
finalise the Foundation's articles of association shortly afterwards based on the
contents of this MSC once passed FCP.
This will coincide with the formal asset transfer of Matrix.org's assets from
New Vector Ltd, and the appointment of the remaining Guardians.

117
specification/proposals_intro.rst
View file

@ -23,12 +23,10 @@ everyone, having the proposal being accepted, then actually having your ideas
implemented as committed changes to the `Specification repository
<https://github.com/matrix-org/matrix-doc>`_.
.. TODO: Replace GH team link with https://matrix.org/foundation or something
Meet the `members of the Core Team
<https://github.com/orgs/matrix-org/teams/spec-core-team/members>`_, a group of
<https://matrix.org/foundation>`_, a group of
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
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
@ -59,13 +57,21 @@ the first place.
* 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 number of bridged end-users reachable on the open Matrix network
* the signal-to-noise ratio of the content on the open Matrix network (i.e. minimising spam)
* the ability for users to discover content on their terms (empowering them to select what to see and what not to see)
* the quality and utility of the Matrix spec (as defined by ease and ability
with which a developer can implement spec-compliant clients, servers, bots,
bridges, and other integrations without needing to refer to any other
external material)
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
* Openness rather than proprietary lock-in
* Interoperability rather than fragmentation
* Cross-platform rather than platform-specific
* Collaboration rather than competition
* Accessibility rather than elitism
* Transparency rather than stealth
@ -73,6 +79,89 @@ their proposed changes to the Matrix protocol:
* Pragmatism rather than perfection
* Proof rather than conjecture
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.
Technical notes
---------------
Proposals **must** develop Matrix as a layered protocol: with new features
building on layers of shared abstractions rather than introducing tight vertical
coupling within the stack. This ensures that new features can evolve rapidly by
building on existing layers and swapping out old features without impacting the
rest of the stack or requiring substantial upgrades to the whole ecosystem.
This is critical for Matrix to rapidly evolve and compete effectively with
centralised systems, despite being a federated protocol.
For instance, new features should be implemented using the highest layer
abstractions possible (e.g. new event types, which layer on top of the existing
room semantics, and so don't even require any API changes). Failing that, the
next recourse would be backwards-compatible changes to the next layer down (e.g.
room APIs); failing that, considering changes to the format of events or the
DAG; etc. It would be a very unusual feature which doesn't build on the
existing infrastructure provided by the spec and instead created new primitives
or low level APIs.
Backwards compatibility is very important for Matrix, but not at the expense of
hindering the protocol's evolution. Backwards incompatible changes to endpoints
are allowed when no other alternative exists, and must be versioned under a new
major release of the API. Backwards incompatible changes to the room algorithm
are also allowed when no other alternative exists, and must be versioned under a
new version of the room algorithm.
There is sometimes a dilemma over where to include higher level features: for
instance, should video conferencing be formalised in the spec, or should it be
implemented via widgets? Should reputation systems be specified? Should search
engine behaviour be specified?
There is no universal answer to this, but the following guidelines should be
applied:
1. If the feature would benefit the whole Matrix ecosystem and is aligned with
the guiding principles above, then it should be supported by the spec.
2. If the spec already makes the feature possible without changing any of the
implementations and spec, then it may not need to be added to the spec.
3. However, if the best user experience for a feature does require custom
implementation behaviour then the behaviour should be defined in the spec
such that all implementations may implement it.
4. However, the spec must never add dependencies on unspecified/nonstandardised
3rd party behaviour.
As a worked example:
1. Video conferencing is clearly a feature which would benefit
the whole ecosystem, and so the spec should find a way to make it happen.
2. Video conferencing can be achieved by widgets without requiring any
compulsory changes to changes to clients nor servers to work, and so could be
omitted from the spec.
3. A better experience could be achieved by embedding Jitsi natively into clients
rather than using a widget...
4. ...except that would add a dependency on unspecified/nonstandardised 3rd party
behaviour, so must not be added to the spec.
Therefore, our two options in the specific case of video conferencing are
either to spec SFU conferencing semantics for WebRTC (or refer to an existing spec
for doing so), or to keep it as a widget-based approach (optionally with widget
extensions specific for more deeply integrating video conferencing use cases).
As an alternative example: it's very unlikely that "how to visualise Magnetic
Resonsance Imaging data over Matrix" would ever be added to the Matrix spec
(other than perhaps a custom event type in a wider standardised Matrix event
registry) given that the spec's existing primitives of file transfer and
extensible events (MSC1767) give excellent tools for transfering and
visualising arbitrary rich data.
Supporting public search engines are likely to not require custom spec features
(other than possibly better bulk access APIs), given they can be implemented as
clients using the existing CS API. An exception could be API features required
by decentralised search infrastructure (avoiding centralisation of power by
a centralised search engine).
Features such as reactions, threaded messages, editable messages,
spam/abuse/content filtering (and reputation systems), are all features which
would clearly benefit the whole Matrix ecosystem, and cannot be implemented in an
interoperable way using the current spec; so they necessitate a spec change.
Process
-------
@ -131,25 +220,25 @@ follows:
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 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
shepherd to help get your proposal through and one will be assigned based
on availability. Having a shepherd is not a requirement for proposal
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
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),
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
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
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
an FCP from beginning. An FCP will only begin when a **75% majority** of core
team members agree on its outcome, and all existing concerns have been
- 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 75% of the members of the
Spec Core Team team agree on its outcome, and all existing concerns have been
resolved.
- 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
@ -239,7 +328,7 @@ Lifetime States
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. Please prefix your proposal's title with ``[WIP]`` to make it easier for reviewers to skim their notifications list.
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 75% 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 Commment Period Complete finished-final-comment-period The final comment period has been completed. Waiting for a demonstration implementation
@ -261,7 +350,7 @@ pull request trackers of the `matrix-doc
<https://github.com/matrix-org/matrix-doc>`_ repo.
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>`_
repo already.