moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

Merge pull request #744 from ralphm/xep-0001-deferred-proposed

Browse Source 
XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft
This commit is contained in:
Ralph Meijer 2019-02-28 12:00:45 +01:00 committed by GitHub
commit f8075873f6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
xep-0001.xml
View File

@ -21,6 +21,13 @@
<shortname>N/A</shortname>
&stpeter;
&dcridland;
&ralphm;
<revision>
<version>1.23.0</version>
<date>2019-01-17</date>
<initials>rm</initials>
<remark><p>Clarify proposing Deferred XEPs for advancement to Draft and introduce the role of Document Shepherd.</p></remark>
</revision>
<revision>
<version>1.22.0</version>
<date>2018-11-08</date>
@ -272,7 +279,7 @@
</ul>
<p>Within 14 days, the Chair of the Approving Body shall poll members of the Approving Body. In rare cases, the Approving Body may decide that the wrong Approving Body may have been chosen. If the Approving Body is in doubt, the XSF Board shall determine the correct Approving Body.</p>
<p>If no member of the Approving Body objects to publication of the proposal, the XMPP Extensions Editor shall accept it as a XEP. The precise rules for polls, including meetings and timeouts, are determined by the Chair of the Approving Body.</p>
<p>If objections are raised by the Approving Body on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.</p>
<p>If objections are raised by the Approving Body on the discussion list of the &SSIG; (the Standards list) or in its meeting, the XEP author is encouraged to address the feedback of the Approving Body and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.</p>
<p>If the proposal is accepted as a XEP, the XMPP Extensions Editor shall do the following:</p>
<ul>
<li>assign it a number</li>
@ -286,16 +293,16 @@
<p>Note well that no special criteria (other than acceptance by the Approving Body and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the XSF, the XMPP Council, or the XMPP developer community. Implementation of Experimental XEPs is encouraged in an exploratory fashion (e.g., in a proof of concept) in order to gain experience with and iteratively improve the protocol defined therein, but such implementations might not be appropriate for deployment in production systems.</p>
</section1>
<section1 topic='Discussion Process' anchor='discussion'>
<p>Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader XMPP developer community. The XEP author is responsible for collecting feedback from the XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, the XEP author should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author shall be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.</p>
<p>Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader XMPP developer community. The XEP author (or Document Shepherd) is responsible for collecting feedback from the XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, they should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author (or Document Shepherd) shall be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.</p>
<p>If an Experimental XEP is inactive (i.e., no updated versions are published) for a period of twelve (12) months, the XMPP Extensions Editor shall automatically change the status of the XEP to Deferred unless it is in the queue of XEPs under active consideration for advancement by the Approving Body; upon submission of an updated version, the XMPP Extensions Editor shall change the status back to Experimental.</p>
</section1>
<section1 topic='Proposal Process' anchor='proposal'>
<p>Before an Experimental XEP may be proposed to the Approving Body for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs), the Approving Body must agree that the XEP is ready to be considered for advancement. Once the Approving Body so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue.</p>
<p>Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.</p>
<p>An Experimental (or Deferred) XEP may be proposed to the Approving Body for advancement to Draft (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs). This can be requested from the Approving Body on the Standards list by, or in collaboration with, the XEP author. In case the XEP has been abandoned by its author(s), any other individual can propose advancement in their stead. The Approving Body will then require a Document Shepherd to take on responsibilities on behalf of the XEP author during the proposal and approval processes. The Approving Body must agree that the XEP is ready to be considered for advancement. Once the Approving Body so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental (or Deferred) to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue.</p>
<p>Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author or Document Shepherd, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.</p>
</section1>
<section1 topic='Approval Process' anchor='approval'>
<p>The precise mechanism for approval depends on the Approving Body.</p>
<p>After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author is free to address the concerns of the Council and to resubmit the XEP for future consideration.</p>
<p>After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author or Document Shepherd is free to address the concerns of the Council and to resubmit the XEP for future consideration.</p>
<p>If the Approving Body decides after Last Call that the XEP is not ready for advancement yet, but nevertheless useful, it can vote to move it back to Experimental state.</p>
<p>If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.</p>
<p>A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.</p>
@ -311,9 +318,9 @@
|
|
+--> Deferred +--> Rejected
| |
| |
Experimental ----> Proposed ----> Draft ----> Final
| | |
| | |
Experimental --+-> Proposed ----> Draft ----> Final
^ | | |
+----------------+ | |
+-----------+---> Deprecated
@ -322,7 +329,7 @@ Experimental ----> Proposed ----> Draft ----> Final
</code>
<p>After an XMPP Extension Protocol has been accepted for publication by the XMPP Council and before it is proposed for advancement to a status of Draft (or retracted or deferred), it shall have a status of Experimental. Publication as an Experimental XEP does not indicate approval of the protocol by the XMPP Council or the broader XMPP community.</p>
<p><em>Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).</em></p>
<p>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in twelve (12) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the XMPP Standards Foundation website for future reference.) Finally, a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.</p>
<p>The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Draft to Final (the criteria for this advancement are described in the following paragraphs). However, an Experimental XEP shall be assigned a status of Deferred if it has not been updated in twelve (12) months (e.g., because of a lack of interest or because it depends on other specifications that have yet to move forward). In addition, rather than being advanced from Proposed to Draft, a Standards Track XEP may be voted to a status of Rejected if the XMPP Council deems it unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor may at some point re-assign it to Experimental status, and that, even if a XEP is Rejected, it is retained in source control and on the XMPP Standards Foundation website for future reference.) Finally, (only) a XEP author may voluntarily remove an Experimental XEP from further consideration, resulting in a status of Retracted.</p>
<p>In order for a Standards Track XEP to advance from Proposed to Draft, it must:</p>
<ol>
<li>fill known gaps in XMPP technologies or deficiencies with existing protocols</li>