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

Hi, On Tue, 2024-06-04 at 11:10 +0200, Maxime Buquet wrote: Of course there are three kinds: (a) Those that consider the protocol ready for use in production software and thus use in production software (b) Those that consider the protocol not ready for use in production software, but don't care because they want the feature and don't want to fix the protocol before using it in production software (c) Those that consider the protocol not ready for use in production software, but need to implement it for compatibility with other production software, because of those in (a) or (b) I'd say that: (a) should just step up and make sure the protocol is turned stable, if it can't be turned to stable, they might even learn why the protocol is in fact not ready for use in production, so it's good for them if they try to move it further. (b) is just irresponsible behavior. Irresponsible towards your users (by shipping things to them you consider broken yourself) and towards the wider community (by requiring everyone to now deal with what is not ready for production in their production software). (c) is the worst that we have it, but impossible not to have as long as there is (a) and (b). I'd hope we can get rid of (a) and (c) through changes in the process and (b) by education. When I talk about production software, I'm referring to the server and clients that are used by thousands of end-users and that are therefor impossible to ensure are properly updated. And I'm talking exclusively about released production software (whatever that means for the project, aka what they suggest their end-users that want somewhat stable software to use). I never said Experimental is an issue. The problem is also not that people want features that are currently only available in Experimental. The problem is that we don't manage to move specifications from Experimental (or even before that) to Stable before they are so widespread that changes are hardly possible. If you can't experiment with it anymore (because it would break production software), then it shouldn't be in Experimental. I was referring to production software implementations, not implementations in test software, feature branches or other experimentation places. MAM should have been Stable for years before it was marked so that everyone has a basis they can develop on. Pidgin is right in saying they don't want to implement something that says "don't ship this to endusers" in it's header. It's just that many others decide to ignore that warning and therefor there is inconsistency in what's supposed to happen with Experimental XEPs. Not sure what you mean. I never said a single person should do a ton of work. I said that if a XEP becomes de-facto stable (because it has widespread production implementations and therefor can't be changed without causing compatibility issues) we should move it to stable. If there is still (backwards-compatible) work to be done for the XEP to be moved to stable and the author can't do it themselves, someone needs to act as a Document Sheppard as outlined in XEP-0001. The process is all defined, we just don't make use of it. I am wondering why you think it's good they use Experimental in production. Wouldn't it be better if the spec they need is in Stable? The list of items I provided obviously only goes if we do all of them: Move things to Stable faster so that developers don't need to use things from Experimental in production. End-users don't decide what is implemented. If end-users see that the message editing they have in their client stops working from one day to the other (because other clients updated to a new, incompatible revision), they will be unhappy. We previously have worked around this by implementing multiple revisions of the same XEP at the same time. And this is where I question the use of the word Experimental (and the warning to not implement it): We do actually consider those revisions to be somewhat Stable and take care of compatibility with them. It's what client and server developers already do today. We look at old revisions to figure out how something was done in previous revisions if it's needed for compatibility. So apparently that old revision is in fact stable enough for it to be used even after it is replaced by a new revision. There's two things that would have improved: a) We can reference and find the version being used due to the different XEP number b) We can tell people in the header that this is in fact ready for use in production as has been shown by a ton of people using it in production. Today XEP-0384 says it's unsuited for production in its header. It probably is not, but even if it is, that's only true for the latest revision. The older revision certain is fit for production. This is not about changing what people implement. This is about our process correctly reflecting what we do in practice. If you just want to rephrase of what Experimental means, we can also do that (making me wonder though what we will need Stable status for). Of course we can just adjust the wording in the header of Experimental XEPs to something like this: Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Experimental status does not imply any encouragement or discouragement to implementations or deployments in production systems. Older revisions of this proposal may be implemented widely, the current revision might be not implemented at all and may be replaced anytime with a newer revisions. Some implementations will consider compatibility with older revisions of this proposal when implementing it, others may not. See [here] for information about implementations in exiting software. With [here] being a link to the data we gathered from DoaP. In this case I would suggest to update the DoaP specification to not point to a single revision when talking about implementation status, but allow to point to multiple revisions (but maybe that's already possible, not sure). Marvin