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.

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.