<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix"><span style="white-space: pre-wrap;">Acked-by: Mir team (<a class="moz-txt-link-abbreviated" href="mailto:alan.griffiths@canonical.com">alan.griffiths@canonical.com</a>)</span></div> <div class="moz-cite-prefix"><span style="white-space: pre-wrap;"> </span></div> <div class="moz-cite-prefix">On 14/11/2019 16:10, Simon Ser wrote:<br> </div> <blockquote type="cite" cite="mid:2362QNRSZ79_8JnAZBkxpgO50pjfVlO-ogkJD-ZsFZydd-UB5j2tHswoxEl-5i0kgZNrt_EXefPIHAhdMG53bifaNycuFtPma9IGimFZvH4=@emersion.fr"> <pre class="moz-quote-pre" wrap="">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]: <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html">https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html</a> Signed-off-by: Drew DeVault <a class="moz-txt-link-rfc2396E" href="mailto:sir@cmpwn.com"><sir@cmpwn.com></a> Signed-off-by: Simon Ser <a class="moz-txt-link-rfc2396E" href="mailto:contact@emersion.fr"><contact@emersion.fr></a> Acked-by: Daniel Stone <a class="moz-txt-link-rfc2396E" href="mailto:daniels@collabora.com"><daniels@collabora.com></a> Acked-by: Pekka Paalanen <a class="moz-txt-link-rfc2396E" href="mailto:pekka.paalanen@collabora.com"><pekka.paalanen@collabora.com></a> Acked-by: Johan Helsing <a class="moz-txt-link-rfc2396E" href="mailto:johan.helsing@qt.io"><johan.helsing@qt.io></a> Acked-by: Roman Gilg <a class="moz-txt-link-rfc2396E" href="mailto:subdiff@gmail.com"><subdiff@gmail.com></a> Cc: Mike Blumenkrantz <a class="moz-txt-link-rfc2396E" href="mailto:michael.blumenkrantz@gmail.com"><michael.blumenkrantz@gmail.com></a> Cc: Jonas Ådahl <a class="moz-txt-link-rfc2396E" href="mailto:jadahl@gmail.com"><jadahl@gmail.com></a> Cc: Carlos Garnacho <a class="moz-txt-link-rfc2396E" href="mailto:carlosg@gnome.org"><carlosg@gnome.org></a> Cc: David Edmundson <a class="moz-txt-link-rfc2396E" href="mailto:david@davidedmundson.co.uk"><david@davidedmundson.co.uk></a> Cc: Christopher James Halse Rogers <a class="moz-txt-link-rfc2396E" href="mailto:raof@ubuntu.com"><raof@ubuntu.com></a> Cc: Alan Griffiths <a class="moz-txt-link-rfc2396E" href="mailto:alan.griffiths@canonical.com"><alan.griffiths@canonical.com></a> --- 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 <a class="moz-txt-link-rfc2396E" href="mailto:michael.blumenkrantz@gmail.com"><michael.blumenkrantz@gmail.com></a> +- GTK/Mutter: Jonas Ådahl <a class="moz-txt-link-rfc2396E" href="mailto:jadahl@gmail.com"><jadahl@gmail.com></a>, + Carlos Garnacho <a class="moz-txt-link-rfc2396E" href="mailto:carlosg@gnome.org"><carlosg@gnome.org></a> +- KWin: Roman Gilg <a class="moz-txt-link-rfc2396E" href="mailto:subdiff@gmail.com"><subdiff@gmail.com></a>, + David Edmundson <a class="moz-txt-link-rfc2396E" href="mailto:david@davidedmundson.co.uk"><david@davidedmundson.co.uk></a> +- Mir: Christopher James Halse Rogers <a class="moz-txt-link-rfc2396E" href="mailto:raof@ubuntu.com"><raof@ubuntu.com></a>, + Alan Griffiths <a class="moz-txt-link-rfc2396E" href="mailto:alan.griffiths@canonical.com"><alan.griffiths@canonical.com></a> +- Qt: Johan Helsing <a class="moz-txt-link-rfc2396E" href="mailto:johan.helsing@qt.io"><johan.helsing@qt.io></a> +- Weston: Pekka Paalanen <a class="moz-txt-link-rfc2396E" href="mailto:pekka.paalanen@collabora.com"><pekka.paalanen@collabora.com></a>, + Daniel Stone <a class="moz-txt-link-rfc2396E" href="mailto:daniel@fooishbar.org"><daniel@fooishbar.org></a> +- wlroots/Sway: Drew DeVault <a class="moz-txt-link-rfc2396E" href="mailto:sir@cmpwn.com"><sir@cmpwn.com></a>, Simon Ser <a class="moz-txt-link-rfc2396E" href="mailto:contact@emersion.fr"><contact@emersion.fr></a> </pre> </blockquote> <p><br> </p> </body> </html>