diff options
Diffstat (limited to 'GOVERNANCE')
| -rw-r--r-- | GOVERNANCE | 149 |
1 files changed, 0 insertions, 149 deletions
diff --git a/GOVERNANCE b/GOVERNANCE deleted file mode 100644 index 912ae5b..0000000 --- a/GOVERNANCE +++ /dev/null @@ -1,149 +0,0 @@ - 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. |