3 Jun
2024
3 Jun
'24
2:10 p.m.
Le lundi 3 juin 2024, 12:37:21 UTC+2 Marvin W a écrit :
Once again, experimental is for that. Writing things down helps to clearly
explain them and how we intend to do them. It's not a starting point for a
feature, but it's definitely a good starting point for wider discussions.
The purpose of inbox is to ask for Council to review
to move to
Experimental, it's not a location for developing a XEP. The location
for developing a XEP from its early stage is Experimental, however
Experimental is also where we have production-grade XEPs that are
widely implemented.
In a perfect world, people would never release and enable functionality
in production software to end-users, that is based on Experimental
XEPs. Evaluation of the move to Stable is based on technical review and
experimental implementations, production implementation is not a
requirement for Stable (we only require production implementation for
Final).
[SNIP]
As explained, we have de-facto reached the state where something that's
considered useful to developers is in Experimental for more than a few
months, we will see it in production and therefor will have to consider
interoperability and compatibility with this specific Experimental
version for at least some time. And that is where the feeling for the
need of a higher bar to Experimental comes from. So to reduce the bar
for Experimental, we have to move to Stable faster or the ecosystem
will move faster than we manage the XEPs.
Experimental is for the specification. Adding whatever status or workflow change
you want will not prevent developers from implementing whatever they feel is
relevant. People have been implementing things that were not official XEPs
because they felt they were relevant, experimental or not (e.g. OTR, OMEMO).
Some teams may choose to implement only stable specifications, others want to
move fast. I'm in the latter case and I'm okay to refactor or even rewrite
something entirely once experience is gained. And I think that both ways are
perfectly fine.
The "experimental" state is clear: it may change and break.
"Stable" may not be desirable for a while. For instance, I've not requested
a
state change on purpose for submitted specifications such as "XEP-0356:
Privileged Entity" because I knew that it would take time and experimentation,
and moving to stable would prevent that.
I've made important changes years after the original submission.
Also, I was working on the only software using it at the beginning; now at
least Slidge, a popular bridge, is using it, and its feedback may be valuable
for updates before moving to stable.
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.
I agree it shouldn't be mandatory, but also we should encourage not
only talking with the community before writing the XEP, but also to
talk with the community before experimenting with the ideas. Because
others might have done that before and/or have ideas that are worth
including in the experimentation. The XEP creation process starts with
the idea, not when writing it down, and IMO we need to find ways and
provide the tools to support XEP creation before the formal writing
process. As explained above, Experimental is implemented in
production in
practice, so retracting or rejecting it won't mean that people don't
have to deal with it. We have the Deprecated state to refer to XEPs
that have production implementations and need to be considered for
interoperability and compatibility, but or not encouraged. However
there is no path from Experimental to Deprecated - because Experimental
shouldn't have had implementations.
As I've mentioned above, experimental or not, whatever new workflow won't
prevent developers from implementing an unstable feature if it is relevant to
them. Experience has shown this to be the case more often than not.
So my personal takeaways on this are:
===
1. We should move to stable faster. Developers that want to release
functionality to their users that requires Experimental XEPs need to
step up and push to accelerate the process, so that they don't have to
release based on Experimental XEPs.
Relevant for some XEPs, but not all. Some time you don't want to move to draft
on purpose, because you want to gain experiment, and feedback from others. You
also need something written as a basis for discussion. My XEP-0356: Privileged
Entity specification is an example.
2. We should encourage the community to interact on
XEPs early.
Essentially make it such that if you plan to work on a topic, you throw
a mail to the mailing list saying you're going to work on it so that
everyone knows and can share any insights they have in the topic. We
can also provide tooling to make this easier or refer to tooling
provided by third parties.
As long as it's not mandatory, it's surely a good thing to interact on
something as early as possible. I personally like to have something written as
a basis for discussions.
3. We should more actively discourage release of functionality based on
ProtoXEP and Experimental XEPs in production (except hidden behind
feature flags or options clearly marked as experimental).
It is already clearly stated. There is a red warning at the very beginning of
the specification. If people chose to implement it, they have reason, and they
know what they do.
Specification is there for interoperability and explaining how things are done.
XSF job is notably to build and maintain them, and help improvement through
discussion and collaboration with the wider community.
It's not the job of the XSF to say to developer how they should present
features, and to tell them (beside current indicators) what to implement or
not.
4. We should not have any bar for Experimental except
for basics,
because Experimental means nobody should implement it in production, so
there is no harm in publishing it.
Beside extreme cases, I'm also advocating for letting most if not all
specification go to experimental. However, beside current warning, it's
developers choice to use them in production.
Best,
Goffi