1# wayland-protocols governance 2 3This document governs the maintenance of wayland-protocols and serves to outline 4the broader process for standardization of protocol extensions in the Wayland 5ecosystem. 6 7## 1. Membership 8 9Membership in wayland-protocols is offered to stakeholders in the Wayland 10ecosystem who have an interest in participating in protocol extension 11standardization. 12 13### 1.1. Membership requirements 14 151. Membership is extended to projects, rather than individuals. 162. Members represent general-purpose projects with a stake in multiple Wayland 17 protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose 18 applications with a stake in only one or two. 193. Each project must provide one or two named individuals as points-of-contact 20 for that project who can be reached to discuss protocol-related matters. 214. During a vote, if two points-of-contact for the same member disagree, the 22 member's vote is considered blank. 23 24### 1.2. Becoming a member 25 261. New members who meet the criteria outlined in 1.1 are established by 27 invitation from an existing member. Projects hoping to join should reach out 28 to an existing member asking for this invitation. 292. New members shall write to the wayland-devel mailing list stating their 30 intention of joining and their sponsor. 313. The sponsor shall respond acknowledging their sponsorship of the membership. 324. A 14 day discussion period for comments from wayland-protocols members will 33 be held. 345. At the conclusion of the discussion period, the new membership is established 35 unless their application was NACKed by a 1/2 majority of all existing members. 36 37### 1.3. Ceasing membership 38 391. A member may step down by writing their intention to do so to the 40 wayland-devel mailing list. 412. A removal vote may be called for by an existing member by posting to the 42 wayland-devel mailing list. This begins a 14 day voting & discussion 43 period. 443. At the conclusion of the voting period, the member is removed if the votes 45 total 2/3rds of all current members. 464. Removed members are not eligible to apply for membership again for a period 47 of 1 year. 485. Following a failed vote, the member who called for the vote cannot 49 call for a re-vote or propose any other removal for 90 days. 50 51## 2. Protocols 52 53### 2.1. Protocol namespaces 54 551. Namespaces are implemented in practice by prefixing each interface name in a 56 protocol definition (XML) with the namespace name, and an underscore (e.g. 57 "xdg_wm_base"). 582. Protocols in a namespace may optionally use the namespace followed by a dash 59 in the name (e.g. "xdg-shell"). 603. The "xdg" namespace is established for protocols letting clients 61 configure its surfaces as "windows", allowing clients to affect how they 62 are managed. 634. The "wp" namespace is established for protocols generally useful to Wayland 64 implementations (i.e. "plumbing" protocols). 655. The "ext" namespace is established as a general catch-all for protocols that 66 fit into no other namespace. 67 68### 2.2. Protocol inclusion requirements 69 701. All protocols found in the "xdg" and "wp" namespaces at the time of writing 71 are grandfathered into their respective namespace without further discussion. 722. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if 73 ACKed by at least 3 members. 743. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if 75 if NACKed by any member. 764. Protocols in the "xdg" and "wp" namespaces must have at least 3 open-source 77 implementations (either 1 client + 2 servers, or 2 clients + 1 server) to be 78 eligible for inclusion. 795. Protocols in the "ext" namespace are eligible for inclusion only if ACKed by 80 at least one other member. 816. Protocols in the "ext" namespace must have at least one open-source client & 82 one open-source server implementation to be eligible for inclusion. 837. "Open-source" is defined as distributed with an Open Source Initiative 84 approved license. 85 86### 2.3. Introducing new protocols 87 881. A new protocol may be proposed by submitting a merge request to the 89 wayland-protocols Gitlab repository. 902. Protocol proposal posts must include justification for their inclusion in 91 their namespace per the requirements outlined in section 2.2. 923. An indefinite discussion period for comments from wayland-protocols members 93 will be held, with a minimum duration of 30 days. Protocols which require a 94 certain level of implementation status, ACKs from members, and so on, should 95 use this time to acquire them. 964. When the proposed protocol meets all requirements for inclusion per section 97 2.2, and the minimum discussion period has elapsed, the sponsoring member may 98 merge their changes in the wayland-protocol repository. 995. Amendments to existing protocols may be proposed by the same process, with 100 no minimum discussion period. 1016. Declaring a protocol stable may be proposed by the same process, with the 102 regular 30 day minimum discussion period. 103 104## 3. Protocol adoption documentation 105 106### 3.1. Adoption website 107 1081. This section is informational. 1092. A website will be made available for interested parties to browse the 110 implementation status of protocols included in wayland-protocols. 1113. A statement from each member of wayland-protocols will be included on the 112 site. 1134. Each protocol will be listed along with its approval status from each member. 1145. The approval statuses are: 115 1. NACK, or "negative acknowledgement", meaning that the member is opposed to 116 the protocol in principle. 117 2. NOPP, or "no opposition", meaning that the member is not opposed to the 118 protocol in principle, but does not provide an implementation. 119 3. ACK, or "acknowledged", meaning that the member supports the protocol in 120 principle, but does not provide an implementation. 121 4. IMPL, or "implemented", meaning that the member supports the protocol and 122 provides an implementation. 1236. Each member may write a short statement expanding on the rationale for their 124 approval status, which will be included on the site. 1257. A supplementary list of implementations will also be provided on the site, 126 which may include implementations supported by non-members. 127 128### 3.2. Changes to the adoption website 129 1301. This section is informational. 1312. A new protocol is added to the website by the sponsoring member at the 132 conclusion of the discussion period (section 2.3.3). 1333. During the discussion period (section 2.3.3), interested parties may express 134 their approval status on the Gitlab merge request. The default approval 135 status for members who do not participate in the discussion is "NOPP". 1364. Members may change their acknowledgement status or support statement at any 137 time after the discussion period (section 2.3.3) has closed by simply merging 138 their update in the wayland-protocols repository. 139 140## 4. Amending this document 141 1421. An amendment to this document may be proposed any member by 143 submitting a merge request on Gitlab. 1442. A 30 day discussion period for comments from wayland-protocols members will 145 be held. 1463. At the conclusion of the discussion period, an amendment will become 147 effective if it's ACKed by at least 2/3rds of all wayland-protocols members, 148 and NACKed by none. The sponsoring member may merge their change to the 149 wayland-protocols repository at this point. 150