From 58f3602d5d785415a5a628518a56797f97f6775f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Thu, 8 Nov 2018 21:02:17 +0100 Subject: [PATCH] XEP-0001: add state transition Proposed -> Experimental MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rationale: Sometimes, XEPs linger in Last Call state. This is probably for the same reason as XEPs which linger in Experimental state (and then become Deferred). However, currently there is no way to put Proposed (= Last Call) XEPs back into Experimental state if one follows the XEP-0001 process by the letter. This is unfortunate, because it puts council into the position to either: - Reject a XEP which is actually useful, but needs work before going to Draft, or - Advance a XEP to Draft which isn’t ready yet, or - Burn cycles of the Editors and Council on perpetuating a Last Call which won’t lead to a conclusion at the current time. (The "burning" of "cycles" is mostly due to the noise created by either officially extending the LC all the time, or having a zombie Proposed XEP hanging around in the list and having to recognize it as zombie and ignoring it.) --- xep-0001.xml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/xep-0001.xml b/xep-0001.xml index 8679a331..9cf63271 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -21,6 +21,12 @@ N/A &stpeter; &dcridland; + + 1.22.0 + 2018-11-08 + jsc +

Officially allow moving XEPs back to Experimental after Last Call.

 + 1.21.1 2016-11-16 @@ -290,6 +296,7 @@

The precise mechanism for approval depends on the Approving Body.

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.

+

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.

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.

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.

Any change in the status of a XEP must be announced on the Standards list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official XSF protocols of the XMPP Standards Foundation.

@@ -307,8 +314,8 @@ | | | | Experimental ----> Proposed ----> Draft ----> Final - | | - | | + ^ | | | + +----------------+ | | +-----------+---> Deprecated | +--> Obsolete