wayland-protocols scope and governance

[Drew DeVault]

I've written up a governance document for us to bikeshed, which is
included at the end of this email. Some comments upfront.

Logistical notes:

- We'll need a wayland-protocols mailing list. This should probably be
  members only, to reduce noise.
- Members will be given push access to the upstream repo. We'll live
  with a gentleman's agreement to play by the rules and invoke the
  member removal process if someone doesn't play nice.
- Someone needs to flesh out the website to show adoption and protocol
  acknowledgement status. Simon was working on something here:

  https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/merge_requests/3

In the interest of keeping this effort moving forward, here are some
actionable tasks we can do, in no particular order:

- Iterate on this document, or propose a new one
- Establish initial membership and status of each protocol
  1. State your intention to be a member, including your point of
     contact and justification per section 1.1, or objection to section
     1.1's requirements
  2. State your project's approval status & statement for any protocols
     you care about
- Mention any important/interesting implementations of the protocols you
  care about
- Decide how & when to ratifiy the new governance model

Aside: wlroots-based compositors have agreed to join under one joint
membership, but given that this reduces our voting power, we may at some
point dissolve into our constituent members if necessary. I think in
practice we'll all get along amicably enough that this won't be a
problem.

Thoughts?

                          wayland-protocols governance

This document governs the maintenance of wayland-protocols and serves to outline
the broader process for standardization of protocol extensions in the Wayland
ecosystem.

                                 1. Membership

Membership in wayland-protocols is offered to stakeholders in the Wayland
ecosystem who have an interest in participating in protocol extension
standardization.

                          1.1. Membership requirements

a. Membership is extended to projects, rather than individuals.
b. Members represent general-purpose projects with a stake in multiple Wayland
   protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose
   applications with a stake in only one or two.
c. Each project must provide an individual point-of-contact for that project who
   can be reached to discuss protocol-related matters.

                             1.2. Becoming a member

a. New members who meet the criteria outlined in 1.1 are established by
   invitation from an existing member. Projects hoping to join should reach out
   to an existing member asking for this invitation.
b. New members shall write to the wayland-protocols mailing list stating their
   intention of joining and their sponsor.
c. The sponsor shall respond acknowledging their sponsorship of the membership.
d. A 14 day discussion period for comments from wayland-protocols members will
   be held.
e. At the conclusion of the discussion period, the new membership is established
   unless their application was NACKed by a 1/2 majority of existing members.

                            1.3. Ceasing membership

a. A member may step down by writing their intention to do so to the
   wayland-protocols mailing list.
b. A removal vote may be called for by an existing member by posting to the
   wayland-protocols mailing list. This begins a 14 day voting & discussion
   period.
c. At the conclusion of the voting period, the member is removed if the votes
   total 2/3rds of members.
d. Removed members are not eligible to apply for membership again for a period
   of 1 year.
e. Following a failed vote, the sponsoring member cannot call for a re-vote or
   propose any other removal for 90 days.

                                  2. Protocols

                            2.1. Protocol namespaces

a. Namespaces are implemented in practice by prefixing each interface name in a
   protocol definition (XML) with the namespace name, and an underscore (e.g.
   "xdg_wm_base").
b. Protocols in a namespace may optionally use the namespace followed by a dash
   in the name (e.g. "xdg-shell").
c. The "xdg" namespace is established for protocols useful for implementing
   desktop-like systems.
d. The "wp" namespace is established for protocols generally useful to Wayland
   implementations (i.e. "plumbing" protocols).
e. The "ext" namespace is established as a general catch-all for protocols that
   fit into no other namespace.

                      2.2. Protocol inclusion requirements

a. All protocols found in the "xdg" and "wp" namespaces at the time of writing
   are grandfathered into their respective namespace without further discussion.
b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if
   ACKed by at least 3 members.
c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
   if NACKed by any member.
d. Protocols in the "xdg" and "wp" namespaces must have at least one open-source
   client implementation & two open-source server implementations to be eligible
   for inclusion.
e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
   at least one member.
f. Protocols in the "ext" namespace must have at least one open-source client &
   one open-source server implementation to be eligible for inclusion.

                         2.3. Introducing new protocols

a. A new protocol may be proposed by posting a patch to the wayland-protocols
   repository to the wayland-protocols mailing list.
b. Protocol proposal posts must include justification for their inclusion in
   their namespace per the requirements outlined in section 2.2.
c. An indefinite discussion period for comments from wayland-protocols members
   will be held, with a minimum duration of 30 days. Protocols which require a
   certain level of implementation status, ACKs from members, and so on, should
   use this time to acquire them.
d. When the proposed protocol meets all requirements for inclusion per section
   2.2, and the minimum discussion period has elapsed, the sponsoring member may
   push their changes to the wayland-protocol repository.
e. Amendments to existing protocols may be proposed by the same process.

                       3. Protocol adoption documentation

                             3.1. Adoption website

a. This section is informational.
b. A website will be made available for interested parties to browse the
   implementation status of protocols included in wayland-protocols.
c. A statement from each member of wayland-protocols will be included on the
   site.
d. Each protocol will be listed along with its approval status from each member.
e. The approval statuses are:
   1. NACK, or "negative acknowledgement", meaning that the member is opposed to
      the protocol in principle.
   2. NOPP, or "no opposition", meaning that the member is not opposed to the
      protocol in principle, but does not provide an implementation.
   3. ACK, or "acknowledged", meaning that the member supports the protocol in
      principle, but does not provide an implementation.
   4. IMPL, or "implemented", meaning that the member supports the protocol and
      provides an implementation.
f. Each member may write a short statement expanding on the rationale for their
   approval status, which will be included on the site.
g. A supplementary list of implementations will also be provided on the site,
   which may include implementations supported by non-members.

                      3.2. Changes to the adoption website

a. This section is informational.
b. A new protocol is added to the website by the sponsoring member at the
   conclusion of the discussion period (section 2.3.c).
c. During the discussion period (section 2.3.c), interested parties may express
   their approval status on the wayland-protocols mailing list. The default
   approval status for members who do not participate in the discussion is
   "NOPP".
d. Members may change their acknowledgement status or support statement at any
   time after the discussion period (section 2.3.c) has closed by simply pushing
   their update to the wayland-protocols repository.

                           4. Amending this document

a. An amendment to this document may be posted to wayland-protocols by any
   member, in the form of a patch.
b. A 30 day discussion period for comments from wayland-protocols members will
   be held.
b. At the conclusion of the discussion period, an amendment will become
   effective if it's ACKed by at least 2/3rds of wayland-protocols members, and
   NACKed by none. The sponsoring member may push their change to the
   wayland-protocols repository at this point.