XSF Process Change Proposals
Hi all, Apologies for this being long. Recent conversations have left me with two distinct impressions: 1) Some people within the XSF have a very different idea of what our process is than I do, that in my view does not match what we have documented. 2) A significant number of those that do share my understanding of the process (and presumably all of those that don't) wish it were different. Frankly, whether I agree with the second group is broadly immaterial - if the consensus is that our process isn't currently what we want it to be, we should change it to something that does have consensus. This message is to try to come up with a set of proposals which can gain consensus, while not totally rewriting the process. As I've noted several times before, I hugely dislike process, and documenting it, but I hate having a documented process that doesn't match what we do (or want to do) even more. I cannot begin to describe how hugely frustrating it is to enter the process in good faith only to discover that's not the process people will enforce. And I'm an old hand, for newcomers it must be even worse. So it's probably time to wade into XEP-0001 once again. I do not have any special rights over XEP-0001, I'm not on the Board or Council, and while I'm an XSF Member that gives no authority over anyone else in the Standards SIG (ie, this list, basically). So anything I say or suggest herein should not be considered final or preferential in any way - you're all welcome (and encouraged) to debate it. So, with that out of the way, here's what I think the rough consensus of our red lines should be (noting I'm not using RFC 2119 language here!): Point A - All specification development should be as open and accessible as possible, operate within a well-documented process, and unequivocally within our IPR policy. Point B - As an organisation, progression along the lifecycle of XEPs should give clear and unambigious signals as to the maturity of the document. Point C - We don't want to dilute Experimental XEPs with "slop", for want of a better word. My impression from people is that there is a concern that because Experimental is very broad in terms of maturity levels it fails on Point B above. Experimental was, I believe, designed to be the rough equivalent to Internet-Drafts in the IETF, which have absolutely no standing, although the XSF "adopts" them as an IETF Working Group does. Over the years, we've introduced technical (and social) changes that mean that specifications in Experimental have become safer to implement and deploy. Proposed currently is a short-lived state that we often ignore - it's from Last Call up to Stable. This shouldn't last more than a couple of weeks, normally. There's no documented quality gate for entering it, though there is a Council vote - then a Last Call, then another Council vote. As such the signal prior to Stable is very fuzzy, so to tighten it up there are a few options. First, we could "left shift" - and I think this is what's been happening. By applying the requirements of Stable (and in some cases, Final) to Experimental, we push things off the beginning of the XSF's process. That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any case leaves no benefit or point to Stable or Final. Second, we could try and refine Experimental. My proposal here - because I do have a concrete proposal - is to attempt to address Point B by making Experimental better defined, and expanding Proposed. Proposal 1 : For Experimental, I propose that XEP-0001 makes it clear that such documents are "works in progress" - it does this already - but also that they may contain errors and ommissions, and may prove unimplementable. This is not, in fact, a change from our current process. Proposal 2 : For Proposed, I suggest we expand this with the quality gate that we expect specifications be implementable, have strong interest from the relevant subsection of the community in implementing, and consensus that they address a problem. Specifications would then enter this as the "final straight" to Stable, have *multiple* Last Calls (I know) and then once the Author is satisfied a Council vote to advance to Stable (or Rejected, or leave it where it is in Proposed). I suggest also introducing a timer that after six months, if not advanced to Stable, they drop back to Experimental. In summary, then, Proposed becomes a strong candidate for Stable. I think this addresses Point B without damage to Point A - that is, Experimental XEPs are more formally "the wild west", and Proposed is "We're pretty sure this works and you should try it". I also think it raises the bar for Stable, which is either a good thing, or a high risk that means we don't have a use for Final. We might wish to note Stable is intended for widespread deployment, rather than mere implementation, and that it's feedback from this widespread deployment that might yet cause changes. I think these are wording changes to match reality, though. I anticipate that some specifications - mostly those that Council are currently accepting - will spend little time in Experimental, and rapidly move to Proposed. That seems like a good thing. Others will spend a lot of time in Experimental, developing. To address Point C, I noticed that in "the old days", we used to require 5% of membership to trigger Council votes, and while I don't wish to "bind" Council, this got me thinking down a line of increasing the signals available to Council. While I'm not worried, personally, about Point C, I do appreciate that others are, and I also note that "AI slop" in particular is a growing problem. Proposal 3 : I propose we introduce a new Call to the SIG (ie, Editor questionnaire sent to the list), which asks for Expressions Of Interest for submitted ProtoXEPs. This should give Council guidance on what documents the community actually wants to work on. XEP-0001 should provide guidance that Council should reject submissions without sufficient interest, and is ordinarily expected to follow the consensus of the SIG. (Which SIG is an interesting question; we normally only have one). I think in the past, and still now on occasion, we've treated the ProtoXEP announcements this way anyway. But formalizing this (and formalizing the idea we're looking for Expressions Of Interest) seems like a good way to gate slop nobody cares about. Presumably if people do care, it is by definition not slop? Proposal 4 : Further, I think it'd be useful to introduce additional guidance as to what is expected of a ProtoXEP submission. First, a new mandatory section of the Problem Statement, such that Council and the SIG a better idea of what the author is hoping to solve, and second, that the ProtoXEP should give a clear idea as to the general approach. This is aimed at explicitly allowing XEPs which are not fully formed, while still providing the kind of information that will let people (SIG and Council) avoid letting in entirely vague slop. Note that neither Proposals 3 or 4 place any limit on Council's veto, nor any recourse/appeal, though it does shift to providing some guidance and expectation. Ultimately, XSF Members just need to vote in sensible, trusted people who follow the process. Related to Proposal 3, there's also: Proposal 5 : Finally I propose we document the Call questionnaires that the Editor sends. This do form part of our process, and a significant part at that. I propose these are documented together in a new XEP, so that they're a little easier to change. Technically these would be Procedural and thus Board approved, but we have historically placed the mechanics of how XEP-0001 is implemented under Council control (see XEP-0143) and I'm inclined to continue that if Board agrees. I'm happy to commit to the time/effort to write these up (though Proposal 5 might be better done by the Editor), but I'd like to gauge interest from the community first, and adjust the proposals as needed to get the best consensus. Once again, apologies for the length, and thanks for reading this far. I owe you a drink, or something. As a final note, I don't think my MUC ProtoXEP would get published under these proposals - but I think I'd have a clearer idea on why - and how to fix it. Dave.
On Thu, 14 May 2026 at 11:37, Dave Cridland <dave@cridland.net> wrote:
Hi all,
Apologies for this being long.
Recent conversations have left me with two distinct impressions:
1) Some people within the XSF have a very different idea of what our process is than I do, that in my view does not match what we have documented.
2) A significant number of those that do share my understanding of the process (and presumably all of those that don't) wish it were different.
I think the community has been divided over the process for many years, it just happens that this particular Council leans in a particular direction, so it has become noticeable. And I understand both sides, such that it's hard to pick one. Before going further, I want to note one aspect of this whole thing which I think is important. A lot of our process, and how it is perceived, derives from terminology that we use. An example of this was when we switched from "Draft" to "Stable". I believe that was a positive change for us to make, even though it didn't update our process, just a single word. It helps to align everyone, both inside and outside our core community. We may want to similarly revisit the label "Experimental" if the definition has (or will be) shifted. We often reference the IETF in process discussions, but our workflow varies from theirs in a number of ways. I'm not saying that's necessarily a bad thing - I don't think we always need to automatically do what the IETF does, nor close any gaps. But it's certainly helpful to look to them for inspiration when we have problems. Now, to get this out of the way - personally, I am not a fan of assigning our official numbers to documents which still have lots of "TODO" and "FIXME" comments. I don't think I've ever submitted a protoXEP with "TODO" comments. I don't think that a document containing only a problem statement and some rough ideas is ready yet - especially when someone might submit a competing document for the same problem. Whether it's file transfer, multi-user A/V conferencing, I think the XSF does the community a disservice by elevating competing proposals for the same problem - it causes confusion and fragmentation. I think my concerns may be linked to what you (Dave) said about the XSF implicitly adopting a document when it is accepted to Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's a clear separation between rough proposals and more serious documents, similarly they have a distinction between documents belonging to an individual and to a working group. We just have one big pool of documents, with statuses which don't always reflect reality and often aren't respected as we would like. Regardless of my personal opinions about the ideal process, it's clear that the role of "Experimental" has traditionally been accepting of rather rough documents. Many authors have submitted (and Councils have accepted) documents containing TODO sections, even Peter back in the day (the Hats XEP was submitted with three competing XML representations of a hat, and it stayed that way for over 10 years). Things have evolved with time, possibly partly due to the changing role of Editor, which became more of a passive/reactive role than one that is actively involved with improving and advancing documents. We got to a point a few years ago where most of the functionality we used in modern implementations was in Experimental. I think we all agree that was a bad place to be in, and I really appreciate the work that Daniel and the past few councils have done to clean that up. But a consequence of that era is that it certainly became far more acceptable to develop and ship software that used XEPs in Experimental status. Experimental de-facto lost its role as a place where documents are really in flux, and shifted more towards the "stable" end of the continuum (hence my comment about potential terminology improvements above - so that everyone has the same expectations of every stage of the process). It's entirely natural that this would result in a stronger defence against things entering Experimental which are not (yet) ready for widespread implementations. Whether we want this change or not, I agree that our documentation almost certainly doesn't reflect this accurately.
Point A - All specification development should be as open and accessible as possible, operate within a well-documented process, and unequivocally within our IPR policy. Point B - As an organisation, progression along the lifecycle of XEPs should give clear and unambigious signals as to the maturity of the document. Point C - We don't want to dilute Experimental XEPs with "slop", for want of a better word.
I find it funny how often you reference the IPR policy, which I barely think about. It's necessary, and it's there. All our specifications are already covered by the IPR policy. Unless you foresee that people will be widely implementing specifications prior to their submission (which I wouldn't recommend), I'm not sure how it factors much into this discussion.
First, we could "left shift" - and I think this is what's been happening. By applying the requirements of Stable (and in some cases, Final) to Experimental, we push things off the beginning of the XSF's process. That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't think it's so extreme that we're applying the requirements of Stable/Final to Experimental like you claim. XEPs are routinely accepted without implementations, but I think you're confusing "Council requires protoXEPs to have implementations" with "Council believes this is a good protocol, with a good approach, that could be implemented" (having an implementation is a good signal which I would expect Council to use, but it's neither a strict requirement nor proof). I expect MUC2 received additional scrutiny because it's in a complex problem area and overlaps with a bunch of existing work over recent years (and no, I'm not primarily referring to "GC3"). I'm not on Council and am far from speaking for them, this is just my reading of the situation based on the discussions I've followed. Because I disagree with your reading of the situation, this proposal of formalizing the shift feels like a straw man (even if not intended that way). The situation is not as bad as it may seem. I understand that you want a significantly lower bar - somewhere for work-in-progress documents to get published without being challenged. People have requested this in the past (I vaguely recall Florian Schmaus argued for it on the lists quite some years ago). I'm not against this necessarily, if it's made clear that such documents are *not* endorsed by the XSF Council. I appreciate that, ironically, this is already in the preamble text for Experimental XEPs. It's not enough though - I don't think such documents should be called XEPs, nor should they be assigned numbers from our XEP series, until they reach a higher bar set by Council. To me, such documents are already fine as a wiki page or whatever. They are not suitable for implementing widely or in software which is to be released to end users (as I think we agree this is what "Experimental" has become), and the IPR agreement is therefore of lesser concern for such documents. If anything, being outside the IPR could be beneficial to discourage use beyond prototyping, a nice feature Experimental doesn't afford. Nevertheless, if we can build out the tooling, I don't see a problem with formalizing a process for submitting and hosting these drafts on xmpp.org.
Second, we could try and refine Experimental. My proposal here - because I do have a concrete proposal - is to attempt to address Point B by making Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your ideas in this proposal (and some we might want to adopt either way). I just don't think I want us to lower the bar for XEPs. But I do want to encourage open and accessible collaboration. I think we can have both. Regards, Matthew
On Thu, 14 May 2026 at 14:16, Matthew Wild <mwild1@gmail.com> wrote:
Now, to get this out of the way - personally, I am not a fan of assigning our official numbers to documents which still have lots of "TODO" and "FIXME" comments. I don't think I've ever submitted a protoXEP with "TODO" comments. I don't think that a document containing only a problem statement and some rough ideas is ready yet - especially when someone might submit a competing document for the same problem. Whether it's file transfer, multi-user A/V conferencing, I think the XSF does the community a disservice by elevating competing proposals for the same problem - it causes confusion and fragmentation.
There's a lot packed into one paragraph here. I'm more of a fan of "TODO" and "FIXME" than I am of specifications which have the same problems but don't call them out, for one thing. I find the "open questions" that some I-Ds have very useful on what to focus on. I also don't think a problem statement and some rough ideas is enough (or at the very least, I don't think that's the consensus). I do think a problem statement and enough specification to understand the approach is very useful. I also believe that having multiple blessed solutions for the same problem is bad, but having multiple approaches documented isn't bad - it's been successful enough before, because in "Experimental", we can properly dig into them. We've also rejected cases where the approaches are too similar. And finally, saying we'll reject anything that addresses the same (or overlapping) problems causes a lot of issues if we ever want to quite deliberately replace other solutions. This is a whole thing I'm happy to defer to Council on, but I hope that by explicitly calling for interest in working on a spec, Council are better informed.
I think my concerns may be linked to what you (Dave) said about the XSF implicitly adopting a document when it is accepted to Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's a clear separation between rough proposals and more serious documents, similarly they have a distinction between documents belonging to an individual and to a working group. We just have one big pool of documents, with statuses which don't always reflect reality and often aren't respected as we would like.
Right, also we list Experimental quite happily on /extensions/ - assuming (for a brief moment) that we accept all my proposals as-is, then we could default to not showing Experimental. I think that'd be a good change. I think we need to provide every facility except numbers anyway, so I think the tooling etc would benefit from just giving them a number too. But that doesn't mean that we can't change their visibility; we don't have the same problems with Deferred, for instance. User Browsing (what an idea!) isn't referenced with the same concern that people place on publishing a new Experimental.
Regardless of my personal opinions about the ideal process, it's clear that the role of "Experimental" has traditionally been accepting of rather rough documents. Many authors have submitted (and Councils have accepted) documents containing TODO sections, even Peter back in the day (the Hats XEP was submitted with three competing XML representations of a hat, and it stayed that way for over 10 years).
Right. I don't think that's a problem in itself. I think it's a problem that it's non-obvious what the difference is between an active, but rough, specification and a specification that's getting solid implementation and is broadly "there". So by lowering the barrier to Experimental (though raising it, still, compared to how it's documented), and pulling Proposed a little sooner, I think we can have that distinction. I may be wrong, of course, but it's a concrete proposal.
Things have evolved with time, possibly partly due to the changing role of Editor, which became more of a passive/reactive role than one that is actively involved with improving and advancing documents. We got to a point a few years ago where most of the functionality we used in modern implementations was in Experimental. I think we all agree that was a bad place to be in, and I really appreciate the work that Daniel and the past few councils have done to clean that up. But a consequence of that era is that it certainly became far more acceptable to develop and ship software that used XEPs in Experimental status. Experimental de-facto lost its role as a place where documents are really in flux, and shifted more towards the "stable" end of the continuum (hence my comment about potential terminology improvements above - so that everyone has the same expectations of every stage of the process).
Agreed with all of that.
It's entirely natural that this would result in a stronger defence against things entering Experimental which are not (yet) ready for widespread implementations. Whether we want this change or not, I agree that our documentation almost certainly doesn't reflect this accurately.
Point A - All specification development should be as open and accessible as possible, operate within a well-documented process, and unequivocally within our IPR policy. Point B - As an organisation, progression along the lifecycle of XEPs should give clear and unambigious signals as to the maturity of the document. Point C - We don't want to dilute Experimental XEPs with "slop", for want of a better word.
I find it funny how often you reference the IPR policy, which I barely think about. It's necessary, and it's there. All our specifications are already covered by the IPR policy. Unless you foresee that people will be widely implementing specifications prior to their submission (which I wouldn't recommend), I'm not sure how it factors much into this discussion.
Right, if you force an unofficial step prior to the process starting, you have also moved the work outside of the IPR policy. That's how it factors in.
First, we could "left shift" - and I think this is what's been happening. By applying the requirements of Stable (and in some cases, Final) to Experimental, we push things off the beginning of the XSF's process. That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't think it's so extreme that we're applying the requirements of Stable/Final to Experimental like you claim. XEPs are routinely accepted without implementations, but I think you're confusing "Council requires protoXEPs to have implementations" with "Council believes this is a good protocol, with a good approach, that could be implemented" (having an implementation is a good signal which I would
That's great if it's a small XEP. And, for that matter, if it's a single-party XEP, like a client-only one, and the submitter is also a client maintainer. But I have been told (twice!) that I Harder for larger cases, and especially where we know even the general idea is somewhat vaguer terms, like Spaces - but Spaces has both activity and progress. It's a success case (at least, so far) and if it passed the bar you've said is applied, then Council were wrong to do so because it's been changed entirely in Experimental so far. And, FWIW, I think Spaces is a *good case*.
expect Council to use, but it's neither a strict requirement nor proof). I expect MUC2 received additional scrutiny because it's in a complex problem area and overlaps with a bunch of existing work over recent years (and no, I'm not primarily referring to "GC3"). I'm not on Council and am far from speaking for them, this is just my reading of the situation based on the discussions I've followed.
That's possible, but also I have explicitly been told a list of requirements and they match (or, indeed, quote) Stable. I think my recent experience is such because in order to achieve the requirements I've been given, I more or less have to write the entirety of a MUC replacement outside the process, and also a set of implementations (client and server), and that feels unwieldy. I don't want to design something that size on my own, that seems insane. I want to work on it, for sure, and draw on the other people, and keep the work in progress in a formal place.
Because I disagree with your reading of the situation, this proposal of formalizing the shift feels like a straw man (even if not intended that way). The situation is not as bad as it may seem.
I think it is, in as much as XEPs appear to be getting much smaller. I don't know how we would create a XEP-0060 (or, indeed, a XEP-0045) these days, and I think we should be able to within the process.
I understand that you want a significantly lower bar - somewhere for work-in-progress documents to get published without being challenged.
That is not what I want. It is also not what I have proposed - what I have proposed *raises* the bar from the documented level, plus extends Proposed so that the current (or higher gate) can be placed there. My proposals try to aim for a gate on Experimental that's based on interest to work on the problem, rather than having to have a complete and full specification.
People have requested this in the past (I vaguely recall Florian Schmaus argued for it on the lists quite some years ago). I'm not against this necessarily, if it's made clear that such documents are *not* endorsed by the XSF Council. I appreciate that, ironically, this is already in the preamble text for Experimental XEPs. It's not enough though - I don't think such documents should be called XEPs, nor should they be assigned numbers from our XEP series, until they reach a higher bar set by Council.
As I say, I'm not precious about numbers. Not calling them XEPs is an interesting idea, though.
I did raise an eyebrow about endorsement by the "XSF Council" - I think documents are endorsed, or not, by the XSF. But anyway, firmly agree that we should make it very clear that Experimental (in my proposed changes) is a work in progress, and so on. I'd overall prefer that the URLs remain stable throughout publication, and that implies they get a number and (at least) a filename including XEP. But redirects are a thing, and if that's the price I can live with it.
To me, such documents are already fine as a wiki page or whatever. They are not suitable for implementing widely or in software which is to be released to end users (as I think we agree this is what "Experimental" has become), and the IPR agreement is therefore of lesser concern for such documents. If anything, being outside the IPR could be beneficial to discourage use beyond prototyping, a nice feature Experimental doesn't afford.
Eeesh. Our IPR policy is mostly (almost entirely) about copyright, which has effects on whether we can make derived works (including republishing as a XEP). You can implement a spec which isn't under our IPR policy, and it's exactly the same - you fully own your implementation, and it's just as weak with respect to patents because, honestly, our IPR policy only avoid hand-waving because rainbow unicorns don't have hands. But we might not be able to republish as a XEP, because the copyright assignment might never come, either because the author refuses or (more likely) because the author has drifted away and simply doesn't realise. Also, there's legal as well as logistic problems with the assignment being after the XSF is already publishing and managing, because assignments are more secure in a contract and there'd be a strong argument there was no consideration. So no, that idea fills me with concern. Also, having *a* gate into the system is useful, not least because time and attention is a valuable resource.
Nevertheless, if we can build out the tooling, I don't see a problem with formalizing a process for submitting and hosting these drafts on xmpp.org.
Second, we could try and refine Experimental. My proposal here - because I do have a concrete proposal - is to attempt to address Point B by making Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your ideas in this proposal (and some we might want to adopt either way). I just don't think I want us to lower the bar for XEPs. But I do want to encourage open and accessible collaboration. I think we can have both.
So your counter-proposal is something along the lines of Experimental becomes unnumbered Non-XEPs, but otherwise is about the same? Dave.
Having read what Dave and Matthew wrote, I think the best proposal would be to not assign numbers to Experimental XEPs, but just a short name and publish them under that short name (we alresdy assign short names to XEPs so that should be a cheap one). I'd also rename Experimental to Draft (or better: XMPP-Draft). Experimental sounds more like "XEP ready, experimenting with implementations" rather than "this is a draft we are working on". Essential this would be a bit like I-D at the IETF and given what Matthew wrote, imho this would be a good thing. I think Dave's proposal to extend the Proposed state is a good idea, too. That way this state would be a bit like the WG-adopted state of an I-D. I'd also assign a XEP number at this state. That way developers can determine the "ready for implementation / gathering of implementational experience" state just by checking if the XEP has a number rather than being an XMPP- Draft with only a short name assigned and listed in an entirely different list/directory over at xmpp.org. (Filtering software by XMPP-Drafts on https://xmpp.org/software would still be beneficial, though.) Once an XMPP-Draft becomes a XEP with a proper number, the old publish place of the X-D could just redirect to the new XEP, I don't think this would be problem. And also what Dave said: an author writing a pre-XEP and then walking away before it becomes a "proper XEP" would be a problem if the pre-XEP was just a wiki page or something else without assigning copyright to the XSF: even if someone wanted to work on the pre-XEP and advance it to a "proper XEP", that wouldn't be possible unless the original author assigned copyright to the XSF, but that may never happen. Even though this legal aspect might in practice never be a problem (because taking the pre-XEP and working on it anyways might never be called out in court by the original author) , it would still be better to avoid it completely. I think the X-D proposal (which would include assigning the copyright for the X-D to the XSF) would solve that legal aspect, too. -tmolitor Am Donnerstag, 14. Mai 2026, 22:27:13 CEST schrieb Dave Cridland:
On Thu, 14 May 2026 at 14:16, Matthew Wild <mwild1@gmail.com> wrote:
Now, to get this out of the way - personally, I am not a fan of assigning our official numbers to documents which still have lots of "TODO" and "FIXME" comments. I don't think I've ever submitted a protoXEP with "TODO" comments. I don't think that a document containing only a problem statement and some rough ideas is ready yet - especially when someone might submit a competing document for the same problem. Whether it's file transfer, multi-user A/V conferencing, I think the XSF does the community a disservice by elevating competing proposals for the same problem - it causes confusion and fragmentation.
There's a lot packed into one paragraph here.
I'm more of a fan of "TODO" and "FIXME" than I am of specifications which have the same problems but don't call them out, for one thing. I find the "open questions" that some I-Ds have very useful on what to focus on.
I also don't think a problem statement and some rough ideas is enough (or at the very least, I don't think that's the consensus). I do think a problem statement and enough specification to understand the approach is very useful.
I also believe that having multiple blessed solutions for the same problem is bad, but having multiple approaches documented isn't bad - it's been successful enough before, because in "Experimental", we can properly dig into them. We've also rejected cases where the approaches are too similar. And finally, saying we'll reject anything that addresses the same (or overlapping) problems causes a lot of issues if we ever want to quite deliberately replace other solutions. This is a whole thing I'm happy to defer to Council on, but I hope that by explicitly calling for interest in working on a spec, Council are better informed.
I think my concerns may be linked to what you (Dave) said about the XSF implicitly adopting a document when it is accepted to Experimental. The IETF doesn't hand out RFC numbers for I-Ds, so it's a clear separation between rough proposals and more serious documents, similarly they have a distinction between documents belonging to an individual and to a working group. We just have one big pool of documents, with statuses which don't always reflect reality and often aren't respected as we would like.
Right, also we list Experimental quite happily on /extensions/ - assuming (for a brief moment) that we accept all my proposals as-is, then we could default to not showing Experimental. I think that'd be a good change.
I think we need to provide every facility except numbers anyway, so I think the tooling etc would benefit from just giving them a number too. But that doesn't mean that we can't change their visibility; we don't have the same problems with Deferred, for instance. User Browsing (what an idea!) isn't referenced with the same concern that people place on publishing a new Experimental.
Regardless of my personal opinions about the ideal process, it's clear that the role of "Experimental" has traditionally been accepting of rather rough documents. Many authors have submitted (and Councils have accepted) documents containing TODO sections, even Peter back in the day (the Hats XEP was submitted with three competing XML representations of a hat, and it stayed that way for over 10 years).
Right. I don't think that's a problem in itself. I think it's a problem that it's non-obvious what the difference is between an active, but rough, specification and a specification that's getting solid implementation and is broadly "there".
So by lowering the barrier to Experimental (though raising it, still, compared to how it's documented), and pulling Proposed a little sooner, I think we can have that distinction. I may be wrong, of course, but it's a concrete proposal.
Things have evolved with time, possibly partly due to the changing role of Editor, which became more of a passive/reactive role than one that is actively involved with improving and advancing documents. We got to a point a few years ago where most of the functionality we used in modern implementations was in Experimental. I think we all agree that was a bad place to be in, and I really appreciate the work that Daniel and the past few councils have done to clean that up. But a consequence of that era is that it certainly became far more acceptable to develop and ship software that used XEPs in Experimental status. Experimental de-facto lost its role as a place where documents are really in flux, and shifted more towards the "stable" end of the continuum (hence my comment about potential terminology improvements above - so that everyone has the same expectations of every stage of the process).
Agreed with all of that.
It's entirely natural that this would result in a stronger defence against things entering Experimental which are not (yet) ready for widespread implementations. Whether we want this change or not, I agree that our documentation almost certainly doesn't reflect this accurately.
Point A - All specification development should be as open and accessible
as possible, operate within a well-documented process, and unequivocally within our IPR policy.
Point B - As an organisation, progression along the lifecycle of XEPs
should give clear and unambigious signals as to the maturity of the document.
Point C - We don't want to dilute Experimental XEPs with "slop", for
want of a better word.
I find it funny how often you reference the IPR policy, which I barely think about. It's necessary, and it's there. All our specifications are already covered by the IPR policy. Unless you foresee that people will be widely implementing specifications prior to their submission (which I wouldn't recommend), I'm not sure how it factors much into this discussion.
Right, if you force an unofficial step prior to the process starting, you have also moved the work outside of the IPR policy.
That's how it factors in.
First, we could "left shift" - and I think this is what's been
happening. By applying the requirements of Stable (and in some cases, Final) to Experimental, we push things off the beginning of the XSF's process. That, I feel very strongly, is wrong, since it violates Point A on all counts, and in any case leaves no benefit or point to Stable or Final.
I agree that there has been a shift (as described above). But I don't think it's so extreme that we're applying the requirements of Stable/Final to Experimental like you claim. XEPs are routinely accepted without implementations, but I think you're confusing "Council requires protoXEPs to have implementations" with "Council believes this is a good protocol, with a good approach, that could be implemented" (having an implementation is a good signal which I would
That's great if it's a small XEP. And, for that matter, if it's a single-party XEP, like a client-only one, and the submitter is also a client maintainer. But I have been told (twice!) that I
Harder for larger cases, and especially where we know even the general idea is somewhat vaguer terms, like Spaces - but Spaces has both activity and progress. It's a success case (at least, so far) and if it passed the bar you've said is applied, then Council were wrong to do so because it's been changed entirely in Experimental so far.
And, FWIW, I think Spaces is a *good case*.
expect Council to use, but it's neither a strict requirement nor proof). I expect MUC2 received additional scrutiny because it's in a complex problem area and overlaps with a bunch of existing work over recent years (and no, I'm not primarily referring to "GC3"). I'm not on Council and am far from speaking for them, this is just my reading of the situation based on the discussions I've followed.
That's possible, but also I have explicitly been told a list of requirements and they match (or, indeed, quote) Stable.
I think my recent experience is such because in order to achieve the requirements I've been given, I more or less have to write the entirety of a MUC replacement outside the process, and also a set of implementations (client and server), and that feels unwieldy. I don't want to design something that size on my own, that seems insane. I want to work on it, for sure, and draw on the other people, and keep the work in progress in a formal place.
Because I disagree with your reading of the situation, this proposal of formalizing the shift feels like a straw man (even if not intended that way). The situation is not as bad as it may seem.
I think it is, in as much as XEPs appear to be getting much smaller. I don't know how we would create a XEP-0060 (or, indeed, a XEP-0045) these days, and I think we should be able to within the process.
I understand that you want a significantly lower bar - somewhere for work-in-progress documents to get published without being challenged.
That is not what I want.
It is also not what I have proposed - what I have proposed *raises* the bar from the documented level, plus extends Proposed so that the current (or higher gate) can be placed there.
My proposals try to aim for a gate on Experimental that's based on interest to work on the problem, rather than having to have a complete and full specification.
People have requested this in the past (I vaguely recall Florian Schmaus argued for it on the lists quite some years ago). I'm not against this necessarily, if it's made clear that such documents are *not* endorsed by the XSF Council. I appreciate that, ironically, this is already in the preamble text for Experimental XEPs. It's not enough though - I don't think such documents should be called XEPs, nor should they be assigned numbers from our XEP series, until they reach a higher bar set by Council.
As I say, I'm not precious about numbers. Not calling them XEPs is an
interesting idea, though.
I did raise an eyebrow about endorsement by the "XSF Council" - I think documents are endorsed, or not, by the XSF.
But anyway, firmly agree that we should make it very clear that Experimental (in my proposed changes) is a work in progress, and so on. I'd overall prefer that the URLs remain stable throughout publication, and that implies they get a number and (at least) a filename including XEP. But redirects are a thing, and if that's the price I can live with it.
To me, such documents are already fine as a wiki page or whatever. They are not suitable for implementing widely or in software which is to be released to end users (as I think we agree this is what "Experimental" has become), and the IPR agreement is therefore of lesser concern for such documents. If anything, being outside the IPR could be beneficial to discourage use beyond prototyping, a nice feature Experimental doesn't afford.
Eeesh.
Our IPR policy is mostly (almost entirely) about copyright, which has effects on whether we can make derived works (including republishing as a XEP). You can implement a spec which isn't under our IPR policy, and it's exactly the same - you fully own your implementation, and it's just as weak with respect to patents because, honestly, our IPR policy only avoid hand-waving because rainbow unicorns don't have hands.
But we might not be able to republish as a XEP, because the copyright assignment might never come, either because the author refuses or (more likely) because the author has drifted away and simply doesn't realise.
Also, there's legal as well as logistic problems with the assignment being after the XSF is already publishing and managing, because assignments are more secure in a contract and there'd be a strong argument there was no consideration.
So no, that idea fills me with concern.
Also, having *a* gate into the system is useful, not least because time and attention is a valuable resource.
Nevertheless, if we can build out the tooling, I don't see a problem with formalizing a process for submitting and hosting these drafts on xmpp.org.
Second, we could try and refine Experimental. My proposal here - because
I do have a concrete proposal - is to attempt to address Point B by making Experimental better defined, and expanding Proposed.
Overall, if we want to lower the bar, I actually like a lot of your ideas in this proposal (and some we might want to adopt either way). I just don't think I want us to lower the bar for XEPs. But I do want to encourage open and accessible collaboration. I think we can have both.
So your counter-proposal is something along the lines of Experimental becomes unnumbered Non-XEPs, but otherwise is about the same?
Dave.
Having read what Dave and Matthew wrote, I think the best proposal would be to not assign numbers to Experimental XEPs, but just a short name and publish them under that short name (we alresdy assign short names to XEPs so that should be a cheap one). I'd also rename Experimental to Draft (or better: XMPP-Draft). Experimental sounds more like "XEP ready, experimenting with implementations" rather than "this is a draft we are working on".
I don't mind this, but I do think there can be a use for an Experimental in between "early draft" and "previously draft now stable". I would honestly suggest we use a dedicated section of the wiki to lower the bar on "early draft" further. Other spec authoring groups have had good luck with this in the past. Rather than getting council or editor involved or making anyone push any buttons, just write stuff and collaborate (under the IPR policy, sure) and when it's "ready" then submit for eyes, votes, process, numbering, namespace versioning, etc. We can of course do this without using a wiki and still force everything through github, but it's more friction. I'll say that, for myself as an implementor, when I want to do something my first stop is always to find every XEP I can that is remotely related sounding or looking, read them all, and bake that into my brain to try to see how what I want to do could be accomplished using existing specs. Sometimes I miss one, but I don't check the status when I do this. Deferred is where all the good XEPs are after all, and why would I write a new spec for something just because the last attempt is languishing? Now maybe I'm doing it wrong and I should ignore Experimental/Deferred, but then I would have ended up starting from scratch on several more things. Maybe that would have been better, but I'm not sure. However you can see how this contributes to wanting stuff in the XEP pool to be at least indicative of "this is maybe a good idea" as an implementor vs "this is a document that says things".
On Fri, 15 May 2026 at 04:23, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I would honestly suggest we use a dedicated section of the wiki to lower the bar on "early draft" further. Other spec authoring groups have had good luck with this in the past. Rather than getting council or editor involved or making anyone push any buttons, just write stuff and collaborate (under the IPR policy, sure) and when it's "ready" then submit for eyes, votes, process, numbering, namespace versioning, etc. We can of course do this without using a wiki and still force everything through github, but it's more friction.
I'm absolutely fine with a bar to entry, and my gut feeling is that a formal point in the process where a ProtoXEP/pre-XEP enters the IPR policy is cleaner. My personal choice of "bar to entry" would be that the XSF feels the specification is worth working on. Low, but enough to avoid the slop. I'm highly aware that other bodies (like the IETF) have problems with AI-generated I-Ds in bulk, currently, and if you've followed the IPv8 stuff, you'll appreciate that anything published anywhere from the XSF, no matter the name, will convince some people that it's definitely approved universally by everyone. I would also like stable URLs, and a wiki makes that hard - but inbox names could easily enough generate a redirect, or we could stamp in a link to the XEP. So, I'm thinking the general idea would be to make inbox be what is now Experimental, and assign a number at Proposed. Given Matt's concern with even using the term Experimental given past implied meanings, I suggest we ditch it and use Inbox. Adding an additional step is exactly the "left shift" that I think is problematic, so I wouldn't like to see "Inbox -> Experimental -> Proposed -> Stable -> Final". We should be able to get the button pushing to be minimal (perhaps even non-existent) for inbox updates, but we'll need to list them on the website, send emails to the SIG for updates, and so on. I think this is all achievable with CI, I might try to see if I can write that in GHA. If these sound sensible I'll update the proposals from my first email later today so we have a concrete set to consider. Dave.
I feel the proposed use of Proposed is a little weird here. Right now, Proposed only really means "Last Call issued". I know that we do have 5 XEPs in Proposed state right now (3 of which had their last call more than a year ago) and those should probably either be moved to Stable or back to Experimental soonish. I personally would rather get rid of this state entirely, as it really isn't a state that has any meaning. In my mind the current Experimental state is somewhat similar to a wg- adopted I-D in IETF: it's no longer a personal endeavor of an individual, but rather something we work on together to improve. I don't support the notion of individual I-D being an Experimental XEP, because we do give significant exposure to Experimental XEPs. I'm not saying that everything that is Experimental right now meets this bar and I would argue that is actually a problem: We do have a bunch of "dead" XEPs where the author at some point wrote some stuff down without hugely consulting if that's actually what people - including themselves - want or need, and so they eventually abandon those XEPs themselves - typically without officially retracting it. Those XEPs add to the fact that people always complain about the hundreds of XEPs and uncertainty what to actually implement. So in line with your proposal, here's my suggestion: - Make what is currently Inbox/ProtoXEP a proper own state: - No requirements, no number assigned, but visible and published on XSF websites if you know the link. Updates announced to standards list. - Introduce also some rule for naming so that there is no collision on names: like the IETF, have each inbox specification (file) name prefixed with the author name. - When a XEP is moved from inbox to regular and gets a number assigned, keep a redirect in the inbox. - XEPs are proposed to Council not by adding it to the Inbox, but by explicit email - Rename Experimental because the name is bad. I would suggest something like "Adopted", but I leave that to a native speaker. We can also reuse the term Proposed here, but given at has an entirely different meaning, that seems odd. - Maybe add some clarification wording that this means that both Council and the author considers this XEP to be worth to work on by the wider community (either by suggesting changes to the XEP or through experimental implementations) - Stop using the Proposed state completely OR be more rigid to move XEPs back to Experimental if they are not moved to Stable. - Lower the bar for Stable (doesn't strictly need to be fully implemented if there is consensus that the stuff should work and be fine) - Move things to Final when we agree we don't want to do any changes to it that are not backwards compatible and also the requirements from XEP-0001 are fulfilled (2 implementations, 6 months without changes). Does that make sense? Marvin Side note: I feel that IPR related concerns could be largely addressed by a Note Well or other explicit wording that the Standards mailing list and XSF Wiki are covered by the IPR policy and wouldn't strictly need changes to the standards process, but I agree that having a somewhat reasonable equivalent to IETFs individual I-D still makes sense. On Fri, 2026-05-15 at 10:42 +0100, Dave Cridland wrote:
On Fri, 15 May 2026 at 04:23, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
I would honestly suggest we use a dedicated section of the wiki to lower the bar on "early draft" further. Other spec authoring groups have had good luck with this in the past. Rather than getting council or editor involved or making anyone push any buttons, just write stuff and collaborate (under the IPR policy, sure) and when it's "ready" then submit for eyes, votes, process, numbering, namespace versioning, etc. We can of course do this without using a wiki and still force everything through github, but it's more friction.
I'm absolutely fine with a bar to entry, and my gut feeling is that a formal point in the process where a ProtoXEP/pre-XEP enters the IPR policy is cleaner. My personal choice of "bar to entry" would be that the XSF feels the specification is worth working on. Low, but enough to avoid the slop. I'm highly aware that other bodies (like the IETF) have problems with AI-generated I-Ds in bulk, currently, and if you've followed the IPv8 stuff, you'll appreciate that anything published anywhere from the XSF, no matter the name, will convince some people that it's definitely approved universally by everyone.
I would also like stable URLs, and a wiki makes that hard - but inbox names could easily enough generate a redirect, or we could stamp in a link to the XEP.
So, I'm thinking the general idea would be to make inbox be what is now Experimental, and assign a number at Proposed. Given Matt's concern with even using the term Experimental given past implied meanings, I suggest we ditch it and use Inbox.
Adding an additional step is exactly the "left shift" that I think is problematic, so I wouldn't like to see "Inbox -> Experimental -> Proposed -> Stable -> Final".
We should be able to get the button pushing to be minimal (perhaps even non-existent) for inbox updates, but we'll need to list them on the website, send emails to the SIG for updates, and so on. I think this is all achievable with CI, I might try to see if I can write that in GHA.
If these sound sensible I'll update the proposals from my first email later today so we have a concrete set to consider.
Dave. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Fri, 15 May 2026 at 11:51, Marvin W. via Standards <standards@xmpp.org> wrote:
I feel the proposed use of Proposed is a little weird here. Right now, Proposed only really means "Last Call issued". I know that we do have 5 XEPs in Proposed state right now (3 of which had their last call more than a year ago) and those should probably either be moved to Stable or back to Experimental soonish. I personally would rather get rid of this state entirely, as it really isn't a state that has any meaning.
I've not actually changed Proposed as much as you might think. I still have it entered as the XEP reaches its first Last Call, it can still bounce back to Experimental or move to Stable. The differences between my proposal and the current documented state are: * A timer that flips it back to Experimental automatically, irrespective of activity. * A Last Call doesn't immediately lead to a Council vote to advance or bounce back. In practice, the latter part often happens anyway - I've known several XEPs that get multiple Last Calls. It seems fine, especially when the Last Call generated a reasonable amount of contention and resultant changes. Codifying that seems like a positive move. And the timer is to stop the stuck-state cases we see. If a XEP is stuck in Proposed, it should - I feel - get bounced back to Experimental. The other changes are in presentation, really. The Council vote on allowing a Last Call always seemed to me to be a formality, whereas this gives it a bit more meaning.
In my mind the current Experimental state is somewhat similar to a wg-adopted I-D in IETF: it's no longer a personal endeavor of an individual, but rather something we work on together to improve. I don't support the notion of individual I-D being an Experimental XEP, because we do give significant exposure to Experimental XEPs. I'm not saying that everything that is Experimental right now meets this bar and I would argue that is actually a problem: We do have a bunch of "dead" XEPs where the author at some point wrote some stuff down without hugely consulting if that's actually what people - including themselves - want or need, and so they eventually abandon those XEPs themselves - typically without officially retracting it. Those XEPs add to the fact that people always complain about the hundreds of XEPs and uncertainty what to actually implement.
Yes, I also suggested not including Experimental in the "default list" of XEPs at https://www.xmpp.org/extensions/ - I think that also might get encourage people to work to advance the stuff they care about.
So in line with your proposal, here's my suggestion: - Make what is currently Inbox/ProtoXEP a proper own state: - No requirements, no number assigned, but visible and published on XSF websites if you know the link. Updates announced to standards list. - Introduce also some rule for naming so that there is no collision on names: like the IETF, have each inbox specification (file) name prefixed with the author name. - When a XEP is moved from inbox to regular and gets a number assigned, keep a redirect in the inbox. - XEPs are proposed to Council not by adding it to the Inbox, but by explicit email
I think there seems to be consensus around that - though I'd quite like a list to be available, just not in the default list. But that may just be me.
- Rename Experimental because the name is bad. I would suggest something like "Adopted", but I leave that to a native speaker. We can also reuse the term Proposed here, but given at has an entirely different meaning, that seems odd. - Maybe add some clarification wording that this means that both Council and the author considers this XEP to be worth to work on by the wider community (either by suggesting changes to the XEP or through experimental implementations)
I worry this is a left shift. But also, that is very close what I was trying to suggest as Experimental... The only difference is s/both Council and the author considers/Council believes the community considers/ I think. But I would put that as the Inbox/ProtoXEP gate, anyway. If you're going to work on a XEP on your own, there's no point involving the XSF at all. If you're going to work on a XEP with others, it ought to be within the XSF's process (and IPR, etc). Prevents the AI (and other) slop.
- Stop using the Proposed state completely OR be more rigid to move XEPs back to Experimental if they are not moved to Stable. - Lower the bar for Stable (doesn't strictly need to be fully implemented if there is consensus that the stuff should work and be fine)
That's not actually a change to Stable, according to the documentation, is it?
- Move things to Final when we agree we don't want to do any changes to it that are not backwards compatible and also the requirements from XEP-0001 are fulfilled (2 implementations, 6 months without changes).
That's also no change, of course, but I think it's not intended to be.
Does that make sense?
Marvin
Side note: I feel that IPR related concerns could be largely addressed by a Note Well or other explicit wording that the Standards mailing list and XSF Wiki are covered by the IPR policy and wouldn't strictly need changes to the standards process, but I agree that having a somewhat reasonable equivalent to IETFs individual I-D still makes sense.
I have to admit I'm unclear on where a "click-through" copyright assignment can work. I think it does work for ProtoXEP submission because there is a clear quid pro quo (I give you the copyright in this exact doc, the XSF agrees to publish it and make it available). This isn't helped by the UK and US laws being quite different, here, to those of most of Western Europe. (the UK and US *do* allow a click-through copyright assignment of future work, I think, whereas Germany, Spain, France and Italy seem not to) Looking at the other thread, I think we might need something much firmer - or, alternatively, we need to change our IPR policy to be licence and not assignment. Dave.
On Fri, 15 May 2026 at 02:16, Thilo Molitor <thilo@eightysoft.de> wrote:
And also what Dave said: an author writing a pre-XEP and then walking away before it becomes a "proper XEP" would be a problem if the pre-XEP was just a wiki page or something else without assigning copyright to the XSF: even if someone wanted to work on the pre-XEP and advance it to a "proper XEP", that wouldn't be possible unless the original author assigned copyright to the XSF, but that may never happen.
I realised there's a much simpler case where keeping pre-XEPs outside the IPR policy causes horror. If multiple people collaborate on a pre-XEP, then they all have a claim on the copyright. It'd be slightly harder to move the pre-XEP under the IPR policy than to relicense a typical open-source project - you need to contact every author, etc. Dave.
Just some thoughts (without responding directly to particular points.) My impression is that the original underlying issue stems from differences in opinion as to what the 'Experimental' state should represent - for some, it's simply the entry point to the XSF process, i.e. I'm working on this and invite community input; for others, it's more a threshold for experimental implementations, i.e. this is pretty much ready, though there may be some rough edges. Ultimately, Experimental has historically covered both of these cases, as it's simply the progression from initial submission to becoming Stable (previously Draft,) but maybe there is some benefit in having a clear separation between the two; though, as always, there may be some disagreement on where precisely to draw the boundary. Some suggestions in this thread are for repurposing the names of 'Draft' and 'Proposed' - I would avoid this as it's more likely to create confusion, given their historical meanings (and uses elsewhere.) The 'Proposed' state is not really being used in practice and is more of a paper-shuffling exercise than anything. Given the above points, my thoughts lead to: 1. Separate Experimental into 'WIP' (work in progress) and 'Adopted;' I think many of the suggestions ultimately amount to this, with minor differences on where to put the boundary, whether to assign numbers, IPR agreement, etc. (My suggestions: IPR agreement for WIP; number at Adoption.) 2. Remove Proposed, as it only acts as a temporary "in Last Call" flag, which is already otherwise signalled. 3. Inbox remains as-is; the number of overall states remains the same.
participants (6)
-
Dave Cridland -
Marvin W. -
Matthew Wild -
Stephen Paul Weber -
Tedd Sterr -
Thilo Molitor