I don't think it matters so much where the compliance suites live or
what process we use to edit them. An XEP seems fine, but so does a page
on the website and we just say "and the council has to approve changes".
The only difference that I see is who hits the publish button: the
website people or
On Fri, 4 Sep 2020 at 13:51, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:
> пт, 4 сент. 2020 г. в 16:37, Georg Lukas :
>
> > 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 i
пт, 4 сент. 2020 г. в 16:37, Georg Lukas :
> 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
thi
Hi Andrew,
thanks for your suggestion!
* Andrew Nenakhov [2020-09-04 11:08]:
> I understand that boy with a hammer treats everything as a nail, but
> come on: if you really want a compliance suite, you shouldn't pollute
> the list of extensions with this day-to-day bureaucracy, but simply
> publ
On 9/4/20 11:06 AM, Andrew Nenakhov wrote:
> […] if you really
> want a compliance suite, you shouldn't pollute the list of extensions
> with this day-to-day bureaucracy, but simply publish a 'compliance
> suite' page on https://xmpp.org/compliance/ URL and update it when
> necessary. You get persi
We don't really care. In part, because we have implemented far too
many extensions that are necessary to provide speedy work on iOS/web
platforms, some of which outright replace the ones listed in those
suites, and, in part, because the XEPs are lately grossly misused by
the XSF, being used now for
