Le lundi 3 juin 2024, 12:37:21 UTC+2 Marvin W a écrit : > 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. 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. > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
