[Standards] Re: Council (and what it does, and what it should do)

Hi, On Mon, 2024-06-03 at 11:02 +0200, Goffi wrote: 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. 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 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. 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