3 Jun
2024
3 Jun
'24
11:02 a.m.
Le dimanche 2 juin 2024, 22:43:27 UTC+2 Peter Saint-Andre a écrit :
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!
I completely agree with this. I don't think that creating another status or
location for proto-proto-XEPs would be beneficial, as it would only add more
confusion. We already have /inbox for this purpose.
I want to add that rejecting a proto-XEP can be highly discouraging for
contributors, especially first-time contributors who may feel that their work
was for nothing (just to be clear: this is not my experience with the proto-
XEP submission that sparked this discussion; but I have been in the XMPP
community for over 15 years and have submitted several specifications before,
so my perspective may be different from that of newcomers).
I suggest that we clearly state somewhere (such as in a "write a proto-XEP"
document) that talking to the community before starting any work is highly
recommended. However, this should not be mandatory, as people may be
experimenting with ideas and specifying them at the same time. The
"Experimental" state is there for the feedback, improvement, and update cycle,
or even retraction.
Council input is valuable, but except in cases where a proto-XEP is really
flawed, it should not be blocking a move to "Experimental" in my opinion.
However, requests for council input should be summarized so that XEP authors
can update their work accordingly. Also, statements such as "I don't like"
or
"this specification is bad" are not helpful and may be disrespectful of the
work done by authors.
All feedback from experienced community members is valuable, and I see no
reason why council feedback should matter more.
We should not be afraid of namespace bumps in the "Experimental" stage. I have
seen people argue against it several times, but I believe this is a mistake.
The "Experimental" stage is for experimentation, and breaking things is a part
of the deal. If people implement experimental specifications, they should be
prepared to update regularly.
Ultimately, the final decision on the relevance of a specification will be made
by implementers and users.
Best,
Goffi