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.