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!
Peter