The following labels are used to help categorize issues:

`spec-omission <https://github.com/matrix-org/matrix-spec/labels/spec-omission>`_
---------------------------------------------------------------------------------

Things which have been implemented but not currently specified. These may range
from entire API endpoints, to particular options or return parameters.

Issues with this label will have been implemented in `Synapse
<https://github.com/matrix-org/synapse>`_. Normally there will be a design
document in Google Docs or similar which describes the feature.

Examples:

* `Spec PUT /directory/list <https://github.com/matrix-org/matrix-doc/issues/417>`_
* `Unspec'd server_name request param for /join/{roomIdOrAlias}
  <https://github.com/matrix-org/matrix-doc/issues/904>`_

`clarification <https://github.com/matrix-org/matrix-spec/labels/clarification>`_
---------------------------------------------------------------------------------

An area where the spec could do with being more explicit.

Examples:

* `Spec the implicit limit on /syncs
  <https://github.com/matrix-org/matrix-spec/issues/200>`_

* `Clarify the meaning of the currently_active flags in presence events
  <https://github.com/matrix-org/matrix-doc/issues/686>`_

`spec-bug <https://github.com/matrix-org/matrix-spec/labels/spec-bug>`_
-----------------------------------------------------------------------

Something which is in the spec, but is wrong.

Note: this is *not* for things that are badly designed or don't work well
(for which see 'improvement' or 'feature') - it is for places where the
spec doesn't match reality.

Examples:

* `swagger is wrong for directory PUT
  <https://github.com/matrix-org/matrix-doc/issues/933>`_

* `receipts section still refers to initialSync
  <https://github.com/matrix-org/matrix-doc/issues/695>`_

`improvement <https://github.com/matrix-org/matrix-spec/labels/improvement>`_
-----------------------------------------------------------------------------

A suggestion for a relatively simple improvement to the protocol.

Examples:

* `We need a 'remove 3PID' API so that users can remove mappings
  <https://github.com/matrix-org/matrix-doc/issues/620>`_
* `We should mandate that /publicRooms requires an access_token
  <https://github.com/matrix-org/matrix-spec/issues/145>`_

`feature <https://github.com/matrix-org/matrix-spec/labels/feature>`_
---------------------------------------------------------------------

A suggestion for a significant extension to the matrix protocol which
needs considerable consideration before implementation.

Examples:

* `Peer-to-peer Matrix <https://github.com/matrix-org/matrix-doc/issues/710>`_
* `Specify a means for clients to "edit" previous messages
  <https://github.com/matrix-org/matrix-spec/issues/184>`_


`wart <https://github.com/matrix-org/matrix-spec/labels/wart>`_
---------------------------------------------------------------

A point where the protocol is inconsistent or inelegant, but which isn't really
causing anybody any problems right now. Might be nice to consider fixing one
day.


`question <https://github.com/matrix-org/matrix-spec/labels/question>`_
-----------------------------------------------------------------------

A thought or idea about the protocol which we aren't really sure whether to
pursue or not.

Examples:

* `Should we prepend anti-eval code to our json responses?
  <https://github.com/matrix-org/matrix-spec/issues/244>`_