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.