Thanks Dave for bringing this up. It is something I believe we really could, should and must do better.
There are two aspects to this: The phase (I) before a XEP gets first presented to council, and the phase (II) after it got "accepted" (by council). Both phases can and should be changed to improve the XEP development process and encourage collaboration. But we mostly can discuss and improve them separately. Regarding (I): Right now new XEPs get developed in various private or public repositories. They do not have a stable URL to reference them, nor are they under the XSF IPR rules. I would like the XSF to adopt a process akin to IETF's Internet Draft (ID) process. This could/would include: - Everyone can create a ProtoXEP, it just has to pass basic lint checks - You get a unique name for it, and a stable URL - Revisions are immutable and have a stable name/URL - There is no requirement for namespace bumps on backwards incompatible changes - No XSF registry entry is performed - XSF IPR rules apply - It is made very obvious that this is an unaccepted, not endorsed, early-stage protocol not for production environments I do have some concrete ideas how to model the process with the existing tools and infrastructure, but I don't feel like we should discuss prior finding a common ground what we want. Regarding (II): This phase also has currently some issues, but they are IMHO far less important than fixing (I). Nevertheless we really should rename 'draft' to something else, e.g. 'stable'. Because, and I believe I am not the only one, 'draft' is what I think of XEPs in (I). Besides that, I'd also like council to really think about blocking a XEP from becoming 'Experimental'. Duplicate functionally should not always be a reason to block, sometimes we may simply want to experiment with a different solution for a problem. And a personal antipathy against a certain technology should also not be a reason to block a XEP from entering 'experimental'. After all, it is not just the council that decides what gets implemented in the wild, the developers have also a say in here. I feel like in the past the distance between council and developers has increased. And that is something we really should avoid, as I do think council's and the community (last calls) review process is beneficial. So we should focus on how to encourage collaboration between council and developers. As a related node: I also believe we are currently lacking a process for collecting breaking changes in (II) in order to minimize namespace bumps. - Florian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
