On Thu, 10 Oct 2019 00:21:43 +0000 Simon Ser <cont...@emersion.fr> wrote:
> This is v4 of the proposal. > > Changes from v3 to v4: relax implementation requirements for inclusion > in "xdg" and "wp" (Jonas, Drew). > > Diff: https://sr.ht/yw0R.txt > > * * * > > 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. > > 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 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 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 last 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 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. > > 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 > push their changes to 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 > pushing > their update to 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 wayland-protocols members, > and > NACKed by none. The sponsoring member may merge their change to the > wayland-protocols repository at this point. > Hi, this looks good to me too. Acked-by: Pekka Paalanen <pekka.paala...@collabora.com> Thanks, pq
pgpVfMaWWBT6E.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
