On Fri, 4 Sep 2020 at 13:51, Andrew Nenakhov < andrew.nenak...@redsolution.com> wrote:
> пт, 4 сент. 2020 г. в 16:37, Georg Lukas <ge...@op-co.de>: > > > This was discussed before, and in my eyes the XEP hammer looks > > sufficiently right for this, as it gives us: > > > > - a proper process to decide what goes into the Compliance Suite > > In efficient organizations a process serves as means to some end. But > this is bureaucracy for bureaucracy's sake. > > > - a version numbering for CS versions > > You can easily achieve it by linking to documents with previous versions. > > > - an archive of previous versions > > The list of extensions to a standard is the best place for an archive, > right. It is obvious that the smaller the standard, the more > accessible it is, so bloating it artificially with non-relevant > information reduces the chance someone will decide to implement it. > > > Making it a dedicated page on the website means that additional process > > needs to be created for the web team (check whether a PR touches the > > magic compliance URL), and for the Council (is that web page maintained/ > > updated in a similar way to an Informational XEP? How do we get > > community feedback? How is a new version approved?). This needs then to > > be written down and approved by Board. > > This, again, is a bureaucracy for the sake of bureaucracy. The process > can be precisely the same, you don't need to bloat the specs with > entries that will be obsoleted in a year just because you need an > archive or an orderly way to update information. > I don't buy it, sorry - XEP numbers are free, and I don't understand why people keep complaining that we have too many specs. It's not like people complain about the IETF having too many RFCs, and nobody thinks implementing the Internet means implementing all of them. I'm all in favour of having a /compliance/ link to the latest compliance document, sure. I'm also fine with that link going to a differently-formatted document that doesn't have the "XEP" feel to it. But when you say "the process can be exactly the same", that's why we've used a XEP, so we don't have a parallel process which we then have to run with an entirely distinct support framework. Doing that would be more costly, not less, than having a bunch of obsolete XEPs. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
