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:
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.
_______________________________________________