On Thu, Oct 10, 2019 at 11:12 AM Simon Ser <cont...@emersion.fr> wrote: > > This is v5 of the proposal. > > Changes from v4 to v5: > - "at least one member" changed to "at least one other member" (Jonas, Pekka) > - Replace remaining occurences of "push" with "merge" (Jonas, Pekka) > - Add a clause defining "open-source" as distributed with an OSI-approved > license (Drew) > > Diff: https://sr.ht/tT-H.txt > > 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> > Cc: Jonas Ådahl <jad...@gmail.com> > > * * * > > 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. >
Qt compile version: 5.12.1 XCB compile version: 1.13.1 > 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 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 wayland-protocols members, > and > NACKed by none. The sponsoring member may merge their change to the > wayland-protocols repository at this point. > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel Thank you all for the work you did on this document. In general I'm in favor of the current draft. I have the following rather technical concerns, but I guess they can be dealt with quickly: New members are proposed by current members but no initial members have been defined. I think we need that in a single sentence, otherwise how could the first members join? I would propose the initial members to be the compositors (in alphabetic order): KWin, mutter, weston, wlroots/Sway. We have defined projects and per project point persons of which there are 1 or 2. In case of 2 and these persons do not agree on the same vote there should be an automatic fallback defined (for example to NOOP in the case of 3.1e). Also the process how these point persons are set is not defined. It says the projects choose them, but how to confirm that easily? I.e. is there an official way to set them? Through a merge request again? Or through an official email address per project? The first one is problematic if there is not yet a point person defined or the only one can not merge anymore for some reason like accident. On another note on IRC some days ago I also raised concerns in regards to the question if there is a quorum defined per vote (member inclusion/expulsion and website, document amendments). It was then pointed out to me that the described vote majorities always are defined in regards to all existing members and not just the voting ones what implicitly defines a quorum. I thought this was not clearly described in the document, but reading it carefully again I think it actually is fine how these votes are defined. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
