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

Add some words about what categories are

Browse source
This commit is contained in:
Travis Ralston 2020-04-22 13:37:50 -06:00
parent 32aecc506f
commit 3c34d83082
1 changed files with 29 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
specification/proposals_intro.rst
View file

@ -341,6 +341,35 @@ Closed proposal-closed A proposal which
Obsolete obsolete A proposal which has been made obsolete by another proposal or decision elsewhere. Obsolete obsolete A proposal which has been made obsolete by another proposal or decision elsewhere.
=============================== ============================= ==================================== =============================== ============================= ====================================
Categories
----------
We use category labels on MSCs to place them into a track of work. The spec core team
decides which of the tracks they are focusing on for the next while and generally makes
an effort to pull MSCs out of that category when possible.
The current categories are:
============ ================= ======================================
Name Github Label Description
============ ================= ======================================
Core kind:core Important for the protocol's success.
Feature kind:feature Nice to have additions to the spec.
Maintenance kind:maintenance Fixes or clarifies existing spec.
============ ================= ======================================
Some examples of core MSCs would be aggregations, cross-signing, and groups/communities.
These are the sorts of things that if not implemented could cause the protocol to
fail or become second-class. Features would be areas like enhanced media APIs,
new transports, and bookmarks in comparison. Finally, maintenance MSCs would include
improving error codes, clarifying what is required of an API, and adding properties
to an API which makes it easier to use.
The spec core team assigns a category to each MSC based on the descriptions above.
This can mean that new MSCs get categorized into an area the team isn't focused on,
though that can always change as priorities evolve. We still encourage that MSCs be
opened, even if not the focus for the time being, as they can still make progress and
even be merged without the spec core team focusing on them specifically.
Proposal Tracking Proposal Tracking
----------------- -----------------