On 6/2/24 12:30 PM, Florian Schmaus wrote:
> On 27/05/2024 15.07, Dave Cridland wrote:
>
>> Equally, I've seen other proposals suggesting much higher bars for
>> accepting a protoXEP, with in effect a pre-Experimental stage tacked
>> on beforehand. I think this would be bad, too, and risks just
>> accreting stages for no real benefit - but it's also essentially
>> inevitable if the bar for accepting a protoXEP is raised too high.
>
> Such a pre-experimental stage already exists, whether we like it or not.
> People work on XMPP extensions, and if the bar is too high, they will
> just work on those extensions outside of the XSF [1].
>
> And that is really a pity and something we should fix.
>
> What I'd like to see is that the XSF creates a place to cater for those
> ProtoXEPs (as how I will refer to pre-experimental XEPs in the
> following). Could be as simple as creating a directory protoxeps/ in
> xsf.git and ensuring that the contents of this directory rendered and
> available under xmpp.org/extensions/protoxeps. I hope that this will get
> us a long way towards fighting the fragmentation that we have [2].
Once again I would like to suggest that we make it easier to publish
experimental XEPs (basically first come, first served à la
Internet-Drafts at the IETF). This was our policy in the early days of
the JSF/XSF, until the Council decided that it needed to exercise more
control or, if you prefer, provide more wise oversight. XEP numbers are
cheap and I don't see why we can't rapidly iterate and innovate within
the XEP space (consider that XEP-0045 went through 30 versions over ~60
days in 2002 before being advanced to Draft).
If that ship has sailed because we now have convinced ourselves that XEP
numbers have deep significance, then by all means let's provide an XSF
place for ProtoXEPs. But we should recognize that the same urge to
control things will rear its head eventually, and then we'll have a
discussion about an XSF place for ProtoProtoXEPs. It's "proto" all the
way down!
Agreed, but also:
The IETF used to have a pretty low bar for Proposed Standard RFCs, and drafts were really just that. However, if you have a gating point - the IETF Last Call for publication as an RFC, (and usually a WG Last Call before that), then people tend to use it, and it causes a "left shift", to borrow someone else's phrase (possibly Scott Bradner's, actually). This has happened in the IETF, so they in effect made I-Ds the new Proposed, as per the meaning in RFC 2026, Proposed became Draft (but not in name), and Internet Standard remained.
While I-Ds are a free-for-all in the IETF, WG-adopted I-Ds are not, and they also involve a gating point, so the IETF frequently has high-numbered revisions of individual I-Ds eventually getting adopted (or discarded). In many WGs, it's the I-D stage where things are implemented, now, with the result that there's an ongoing discussion about whether a WG can stipulate that drafts have to have implementations before adoption...
So gating functions get used, and generally more than they should be especially the further left they are, pushing the entire process along a notch.
Dave.