Hi, On Mon, 2024-06-03 at 11:02 +0200, Goffi wrote: > 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.
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). However, practice has shown that in the past our processes have been to slow. The time from drafting a rough idea to implementing it in production software is often shorter than the time from rough idea to get a XEP in Experimental, let alone Stable. I tried to circumvent this by writing XEP-0447 (and the bunch of other XEPs I submitted at the same time) way ahead of when I want to invest the time to implement it. I personally haven't done a proper implementation of most of its features yet and was rather gathering feedback from the list. So there was no need to implement this for interoperability from anyone (as there was for some other early stage XEPs), yet there already have been implementations from the community in released software. This underlines my point that Experimental is considered "ready for use in production software" by some. > 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). 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. > 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. > The > "Experimental" state is there for the feedback, improvement, and > update cycle, > or even retraction. 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. > Ultimately, the final decision on the relevance of a specification > will be made > by implementers and users. 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. 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. 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). 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. === I'd love to get feedback on these 4 points so we can turn them into actionable items. Marvin _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
