[PATCH wayland-protocols] Add governance document

Christopher James Halse Rogers raof at ubuntu.com
Fri Nov 15 00:24:47 UTC 2019



On Fri, Nov 15, 2019 at 00:10, Simon Ser <contact at emersion.fr> wrote:
> 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 at cmpwn.com <mailto:sir at cmpwn.com>>
> Signed-off-by: Simon Ser <contact at emersion.fr 
> <mailto:contact at emersion.fr>>
> Acked-by: Daniel Stone <daniels at collabora.com 
> <mailto:daniels at collabora.com>>
> Acked-by: Pekka Paalanen <pekka.paalanen at collabora.com 
> <mailto:pekka.paalanen at collabora.com>>
> Acked-by: Johan Helsing <johan.helsing at qt.io 
> <mailto:johan.helsing at qt.io>>
> Acked-by: Roman Gilg <subdiff at gmail.com <mailto:subdiff at gmail.com>>
> Cc: Mike Blumenkrantz <michael.blumenkrantz at gmail.com 
> <mailto:michael.blumenkrantz at gmail.com>>
> Cc: Jonas Ådahl <jadahl at gmail.com <mailto:jadahl at gmail.com>>
> Cc: Carlos Garnacho <carlosg at gnome.org <mailto:carlosg at gnome.org>>
> Cc: David Edmundson <david at davidedmundson.co.uk 
> <mailto:david at davidedmundson.co.uk>>
> Cc: Christopher James Halse Rogers <raof at ubuntu.com 
> <mailto:raof at ubuntu.com>>
> Cc: Alan Griffiths <alan.griffiths at canonical.com 
> <mailto:alan.griffiths at 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.blumenkrantz at gmail.com 
> <mailto:michael.blumenkrantz at gmail.com>>
> +- GTK/Mutter: Jonas Ådahl <jadahl at gmail.com 
> <mailto:jadahl at gmail.com>>,
> +  Carlos Garnacho <carlosg at gnome.org <mailto:carlosg at gnome.org>>
> +- KWin: Roman Gilg <subdiff at gmail.com <mailto:subdiff at gmail.com>>,
> +  David Edmundson <david at davidedmundson.co.uk 
> <mailto:david at davidedmundson.co.uk>>
> +- Mir: Christopher James Halse Rogers <raof at ubuntu.com 
> <mailto:raof at ubuntu.com>>,
> +  Alan Griffiths <alan.griffiths at canonical.com 
> <mailto:alan.griffiths at canonical.com>>
> +- Qt: Johan Helsing <johan.helsing at qt.io 
> <mailto:johan.helsing at qt.io>>
> +- Weston: Pekka Paalanen <pekka.paalanen at collabora.com 
> <mailto:pekka.paalanen at collabora.com>>,
> +  Daniel Stone <daniel at fooishbar.org <mailto:daniel at fooishbar.org>>
> +- wlroots/Sway: Drew DeVault <sir at cmpwn.com <mailto:sir at cmpwn.com>>, 
> Simon Ser <contact at emersion.fr <mailto:contact at emersion.fr>>
> 

Acked-by: Christopher James Halse Rogers 
<christopher.halse.rogers at canonical.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191115/1558e958/attachment-0001.html>


More information about the wayland-devel mailing list