The standards process specified herein has been developed and refined in order to meet these objectives.
+The XEPs are kept in source control within a Git repository. Full instructions for accessing these files can be found at <http://xmpp.org/about-xmpp/xsf/xsf-source-control/>. References within this document to "source control" refer to this repository.
+The latest versions of XEPs are published at <http://www.xmpp.org/extensions/>, and this is the canonical URL for accessing them.
+It is possible to suggest changes to a XEP either by feedback to a relevant mailing list (typically the &SSIG; mailing list), or directly by supplying a patch (eg, a Pull Request) against the source control system. Either of those is treated identically within the terms of this document (though of course the mechanics differ). Contributors are advised to refer to &XSFIPR; for the implications.
+The five XEP types are described in the following sections.
The approving body for all Standards Track, Informational, and Historical XEPs is the XMPP Council; the approving body for Humorous XEPs is the XMPP Extensions Editor; and the approving body for Procedural XEPs may be either the &BOARD; or the XMPP Council.
@@ -303,7 +324,7 @@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.
+The XEP author incorporates the feedback by creating source control patches (such as Pull Requests), in line with the preferred method in &xep0143;. Direct changes to an Experimental XEP, such as a contributor providing a patch (or Pull Request on GitHub), are still the responsibility of the XEP author, and are only applied if the XEP author agrees (unless these are editorial changes; see below). If a XEP has multiple authors, while agreement is sought from all authors, only those opinions from responsive authors are considered. If the Approving Body feels that the XEP author is not responsive, another author may be added unilaterally by the Approving Body.
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.
-Only substantial, non-editorial changes (e.g. those that would cause an updated version of 0.1 to 0.2, not editorial updates from 0.1.1 to 0.1.2) count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state.
+Some changes are considered "merely editorial", such as correcting typographical errors, and similar "fixes" to existing documents. These may be applied by the XMPP Extensions Editor at their discretion, without contacting the Author in advance (or even at all).
+Only substantial, non-editorial changes (e.g. those that would cause an updated version of 0.1 to 0.2, not editorial updates from 0.1.1 to 0.1.2) count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state.
+An Experimental (or Deferred) XEP may be proposed to the Approving Body for advancement to Stable (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.
@@ -348,7 +373,7 @@ Experimental --+-> Proposed ----> Stable ---> FinalAfter an XMPP Extension Protocol has been accepted for publication by the XMPP Council and before it is proposed for advancement to a status of Stable (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.
Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Stable. 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).
-The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Stable 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 Stable, 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.
+The ideal path is for a Standards Track XEP is to be advanced by the XMPP Council from Proposed to Stable 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 Stable, 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.
In order for a Standards Track XEP to advance from Proposed to Stable, it must: