Editorial changes

xep-0001.xml

@@ -22,6 +22,22 @@
   &stpeter;
   &dcridland;
   &ralphm;
+  <revision>
+    <version>1.26.0</version>
+    <date>2024-12-24</date>
+    <initials>dwd</initials>
+    <remark>
+      <ul>
+        <li>Surface (and correct) the source control information.</li>
+        <li>Surface the publication URL (although I assume anyone reading this has figured that one out by now).</li>
+        <li>Surface the contributor side of things.</li>
+        <li>Add bit about XEP authors making PRs if they don't exist - this is "new" rather than documenting existing practice.</li>
+        <li>Add bit about PRs getting XEP author approval (existing practice hithertofore undocumented).</li>
+        <li>Add bit about Council (etc) adding authors if they drop off (existing practice hithertofore undocumented).</li>
+        <li>Add note to clarify that Retraction doesn't mean Deletion (existing practice, documented, but has been misunderstood before).</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>1.25.0</version>
     <date>2024-03-11</date>
@@ -317,9 +333,12 @@
 </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 responsibility 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>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.</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>
+  <section2 topic="Editorial Changes" anchor="editorial">
+    <p>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).</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>
+  </section2>
 </section1>
 <section1 topic='Proposal Process' anchor='proposal'>
   <p>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.</p>