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 <s...@cmpwn.com <mailto:s...@cmpwn.com>>
Signed-off-by: Simon Ser <cont...@emersion.fr
<mailto:cont...@emersion.fr>>
Acked-by: Daniel Stone <dani...@collabora.com
<mailto:dani...@collabora.com>>
Acked-by: Pekka Paalanen <pekka.paala...@collabora.com
<mailto:pekka.paala...@collabora.com>>
Acked-by: Johan Helsing <johan.hels...@qt.io
<mailto:johan.hels...@qt.io>>
Acked-by: Roman Gilg <subd...@gmail.com <mailto:subd...@gmail.com>>
Cc: Mike Blumenkrantz <michael.blumenkra...@gmail.com
<mailto:michael.blumenkra...@gmail.com>>
Cc: Jonas Ådahl <jad...@gmail.com <mailto:jad...@gmail.com>>
Cc: Carlos Garnacho <carl...@gnome.org <mailto:carl...@gnome.org>>
Cc: David Edmundson <da...@davidedmundson.co.uk
<mailto:da...@davidedmundson.co.uk>>
Cc: Christopher James Halse Rogers <r...@ubuntu.com
<mailto:r...@ubuntu.com>>
Cc: Alan Griffiths <alan.griffi...@canonical.com
<mailto:alan.griffi...@canonical.com>>
---
GOVERNANCE | 149
+++++++++++++++++++++++++++++++++++++++++++++++++++++
MEMBERS | 11 ++++
2 files changed, 160 insertions(+)
create mode 100644 GOVERNANCE
create mode 100644 MEMBERS
diff --git a/GOVERNANCE b/GOVERNANCE
new file mode 100644
index 000000000000..912ae5bb8808
--- /dev/null
+++ b/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.
diff --git a/MEMBERS b/MEMBERS
new file mode 100644
index 000000000000..9f8ace57b4ba
--- /dev/null
+++ b/MEMBERS
@@ -0,0 +1,11 @@
+- EFL/Enlightenment: Mike Blumenkrantz
<michael.blumenkra...@gmail.com
<mailto:michael.blumenkra...@gmail.com>>
+- GTK/Mutter: Jonas Ådahl <jad...@gmail.com
<mailto:jad...@gmail.com>>,
+ Carlos Garnacho <carl...@gnome.org <mailto:carl...@gnome.org>>
+- KWin: Roman Gilg <subd...@gmail.com <mailto:subd...@gmail.com>>,
+ David Edmundson <da...@davidedmundson.co.uk
<mailto:da...@davidedmundson.co.uk>>
+- Mir: Christopher James Halse Rogers <r...@ubuntu.com
<mailto:r...@ubuntu.com>>,
+ Alan Griffiths <alan.griffi...@canonical.com
<mailto:alan.griffi...@canonical.com>>
+- Qt: Johan Helsing <johan.hels...@qt.io
<mailto:johan.hels...@qt.io>>
+- Weston: Pekka Paalanen <pekka.paala...@collabora.com
<mailto:pekka.paala...@collabora.com>>,
+ Daniel Stone <dan...@fooishbar.org <mailto:dan...@fooishbar.org>>
+- wlroots/Sway: Drew DeVault <s...@cmpwn.com <mailto:s...@cmpwn.com>>,
Simon Ser <cont...@emersion.fr <mailto:cont...@emersion.fr>>
