Authors and Contributions

xep-0001.xml

@@ -248,6 +248,11 @@
   </ol>
   <p>The standards process specified herein has been developed and refined in order to meet these objectives.</p>
 </section1>
+ <section1 topic="Storage and Contribution" anchor="contribution">
+   <p>The XEPs are kept in source control within a Git repository. Full instructions for accessing these files can be found at &lt;<link url='http://xmpp.org/about-xmpp/xsf/xsf-source-control/'>http://xmpp.org/about-xmpp/xsf/xsf-source-control/</link>&gt;. References within this document to "source control" refer to this repository.</p>
+   <p>The latest versions of XEPs are published at &lt;<link url='http://www.xmpp.org/extensions/'>http://www.xmpp.org/extensions/</link>&gt;, and this is the canonical URL for accessing them.</p>
+   <p>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.</p>
+ </section1>
 <section1 topic='XEP Types' anchor='types'>
   <p>The five XEP types are described in the following sections.</p>
   <p>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.</p>
@@ -303,7 +308,7 @@
     <li>assign it a number</li>
     <li>specify an appropriate type</li>
     <li>specify a status of Experimental (or Active for Humorous XEPs)</li>
-    <li>add it to source control <note>XEPs are kept under source control in the 'xmpp' module and 'extensions' directory of the XSF Git repository; instructions for accessing these files can be found at &lt;<link url='http://xmpp.org/about-xmpp/xsf/xsf-source-control/'>http://xmpp.org/about-xmpp/xsf/xsf-source-control/</link>&gt;.</note></li>
+    <li>add it to source control</li>
     <li>add tracking information to the XEPs database</li>
     <li>publish version 0.1 of the XEP to the xmpp.org website <note>The canonical URL for accessing XMPP Extensions is &lt;<link url='http://www.xmpp.org/extensions/'>http://www.xmpp.org/extensions/</link>&gt;.</note></li>
     <li>publicly announce the existence of the XEP by sending a message to the Standards list</li>
@@ -312,6 +317,7 @@
 </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 (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>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 reponsibility of the XEP author, and are only applied if the XEP author agrees. 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.</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>
   <p>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 <em>activity</em> (or <em>updates</em>) for the purpose of considering moving a XEP from or to Deferred state.</p>
 </section1>
@@ -348,7 +354,7 @@ Experimental --+-> Proposed ----> Stable ---> 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 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.</p>
     <p><em>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).</em></p>
-    <p>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.</p>
+    <p>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. <note>Retracting a XEP does not mean it is removed from source control; the XSF still owns it as per &XSFIPR;</note></p>
     <p>In order for a Standards Track XEP to advance from Proposed to Stable, it must:</p>
     <ol>
       <li>fill known gaps in XMPP technologies or deficiencies with existing protocols</li>