On Fri, Nov 15, 2019 at 12:10:58AM +0000, Simon Ser 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 <s...@cmpwn.com> > Signed-off-by: Simon Ser <cont...@emersion.fr> > Acked-by: Daniel Stone <dani...@collabora.com> > Acked-by: Pekka Paalanen <pekka.paala...@collabora.com> > Acked-by: Johan Helsing <johan.hels...@qt.io> > Acked-by: Roman Gilg <subd...@gmail.com> > Cc: Mike Blumenkrantz <michael.blumenkra...@gmail.com> > Cc: Jonas Ådahl <jad...@gmail.com> > Cc: Carlos Garnacho <carl...@gnome.org> > Cc: David Edmundson <da...@davidedmundson.co.uk> > Cc: Christopher James Halse Rogers <r...@ubuntu.com> > Cc: Alan Griffiths <alan.griffi...@canonical.com>
Acked-by: Jonas Ådahl <jad...@gmail.com> Jonas > --- > 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> > +- GTK/Mutter: Jonas Ådahl <jad...@gmail.com>, > + Carlos Garnacho <carl...@gnome.org> > +- KWin: Roman Gilg <subd...@gmail.com>, > + David Edmundson <da...@davidedmundson.co.uk> > +- Mir: Christopher James Halse Rogers <r...@ubuntu.com>, > + Alan Griffiths <alan.griffi...@canonical.com> > +- Qt: Johan Helsing <johan.hels...@qt.io> > +- Weston: Pekka Paalanen <pekka.paala...@collabora.com>, > + Daniel Stone <dan...@fooishbar.org> > +- wlroots/Sway: Drew DeVault <s...@cmpwn.com>, Simon Ser > <cont...@emersion.fr> > -- > 2.24.0 > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
