[Standards] Re: XSF Process Change Proposals

On Thu, 14 May 2026 at 11:37, Dave Cridland <dave(a)cridland.net> wrote: 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. 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. 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. 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