Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0001 Authors and Contributions #1407

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

XEP-0001 Authors and Contributions #1407

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8a6cdd8
Authors and Contributions
dwd Dec 15, 2024
df309c9
typos
dwd Dec 15, 2024
8fd49fe
Editorial changes
dwd Dec 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 28 additions & 3 deletions xep-0001.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -248,6 +264,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>
Expand Down Expand Up @@ -303,7 +324,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>
Expand All @@ -312,8 +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 (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>
Expand Down Expand Up @@ -348,7 +373,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>
Expand Down
Loading