Add governance document

The idea of a better-defined governance model for wayland-protocols has
been discussed for quite a while [1].

A new GOVERNANCE document describes how changes to the wayland-protocols
repository are accepted. A set of members representing projects can vote
on merge requests sent via GitLab. The initial list of members is
available in the MEMBERS file.

[1]: https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html

Signed-off-by: Drew DeVault <sir@cmpwn.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Johan Helsing <johan.helsing@qt.io>
Acked-by: Roman Gilg <subdiff@gmail.com>
Acked-by: Christopher James Halse Rogers <raof@ubuntu.com>
Acked-by: Alan Griffiths <alan.griffiths@canonical.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Cc: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Cc: Carlos Garnacho <carlosg@gnome.org>
Cc: David Edmundson <david@davidedmundson.co.uk>

GOVERNANCE

@@ -0,0 +1,149 @@
+                          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 one or two named individuals as points-of-contact
+   for that project who can be reached to discuss protocol-related matters.
+d. During a vote, if two points-of-contact for the same member disagree, the
+   member's vote is considered blank.
+
+                             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-devel 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 all existing members.
+
+                            1.3. Ceasing membership
+
+a. A member may step down by writing their intention to do so to the
+   wayland-devel mailing list.
+b. A removal vote may be called for by an existing member by posting to the
+   wayland-devel 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 all current members.
+d. Removed members are not eligible to apply for membership again for a period
+   of 1 year.
+e. Following a failed vote, the member who called for the vote 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 letting clients
+   configure its surfaces as "windows", allowing clients to affect how they
+   are managed.
+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 3 open-source
+   implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be
+   eligible for inclusion.
+e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by
+   at least one other 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.
+g. "Open-source" is defined as distributed with an Open Source Initiative
+   approved license.
+
+                         2.3. Introducing new protocols
+
+a. A new protocol may be proposed by submitting a merge request to the
+   wayland-protocols Gitlab repository.
+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
+   merge their changes in the wayland-protocol repository.
+e. Amendments to existing protocols may be proposed by the same process, with
+   no minimum discussion period.
+f. Declaring a protocol stable may be proposed by the same process, with the
+   regular 30 day minimum discussion period.
+
+                       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 Gitlab merge request. 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 merging
+   their update in the wayland-protocols repository.
+
+                           4. Amending this document
+
+a. An amendment to this document may be proposed any member by
+   submitting a merge request on Gitlab.
+b. A 30 day discussion period for comments from wayland-protocols members will
+   be held.
+c. At the conclusion of the discussion period, an amendment will become
+   effective if it's ACKed by at least 2/3rds of all wayland-protocols members,
+   and NACKed by none. The sponsoring member may merge their change to the
+   wayland-protocols repository at this point.

MEMBERS

@@ -0,0 +1,13 @@
+                           wayland-protocols members
+
+- EFL/Enlightenment: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
+- GTK/Mutter: Jonas Ådahl <jadahl@gmail.com>,
+  Carlos Garnacho <carlosg@gnome.org>
+- KWin: Roman Gilg <subdiff@gmail.com>,
+  David Edmundson <david@davidedmundson.co.uk>
+- Mir: Christopher James Halse Rogers <raof@ubuntu.com>,
+  Alan Griffiths <alan.griffiths@canonical.com>
+- Qt: Johan Helsing <johan.helsing@qt.io>
+- Weston: Pekka Paalanen <pekka.paalanen@collabora.com>,
+  Daniel Stone <daniel@fooishbar.org>
+- wlroots/Sway: Drew DeVault <sir@cmpwn.com>, Simon Ser <contact@emersion.fr>