XSF Discussion - 2020-09-04

flow: I'm pretty sure we had a discussion about making Compliance Suite a fixed document instead of a XEP, either one or two years ago, and then decided that we don't have the process for Council to make such a document outside of the XEP process

Ge0rG, I know

flow: I don't see how the situation might have changed since then

I'd believe that it should be trivial to say that council has control over whatever appears behind xmpp.org/compliance, or otherwise we are doing something wrong

it would feel like we are trapped in our self-imposed bureaucracy

what's wrong with having a redirect from /compliance/ to the current compliance suite xep?

Ge0rG, some of the (valid, imho) points andrew mentions would still apply, no?

that said, a redirect would probably be an inprovement

Does it really matter if it's a XEP or a web page or a redirect?

flow: some of the points are valid, yes, but XEP numbers are rather cheap, and we would end up re-inventing XEP Process just for this page.

Zash, I think it does

and after all it's easy to suggest changes if the burden of implementing them properly is with somebody else.

even if it is just because someone forgets to update to redirect, but I think there is more to that

I'm pretty sure that the redirect was also suggested last year.

or two years ago.

maybe somebody™ should figure out how to make one in Pelican and open a PR?

it sure was, but I really think it should be a compliance.md that council edits

flow: see above.

Ge0rG, which above are you referring to?

flow: > we would end up re-inventing XEP Process just for this page. > it's easy to suggest changes if the burden of implementing them properly is with somebody else.

Ge0rG, I am not sure what you want me to tell. But I would implement a compliance.md if you ask me to

as it stands now, publishing the Compliance Suite is a job that has burned through multiple authors over the years, and as its current author I can say that it's Good Enough™

assuming that it is used later on (of course)

flow: making it a dedicated page on the website means that additional process needs to be created for the commteam/web team (check whether a PR touches the magic compliance URL), for the Council (is that web page similar to an Informational XEP?). This needs to be written down and approved by Board.

flow: that's pretty much work compared to "just keep doing it as is now and create a redirect"

I'd simply write "The XSF Council maintains the pages of the XMPP compliance suite under the xmpp.org domain" into the right document

flow: PR welcome

CS2021 doesn't have a XEP number yet. It's not too late.

but given that you need a "current" compliance suite, an archive of previous compliance suites and some sort of versioning for them, XEPs don't look so bad as a vehicle after all

So that'd be XEP-0001, which makes it a Board matter. Have fun with the process! :)

I fear that someone will tell me that it belongs into the bylaws and then we need some sort of membership vote and we end up in some sort of bureaucracy hell

Zash: Board would delegate to Council for pre-approval

flow: so just submit a PR for the redirect then ;)

xmpp.org/compliance/2019 xmpp.org/compliance/2018 etc

bbl

or maybe create a small page that describes what the CS is about and links to all the versions?

that would be an improvement that can be implemented immediately!

Maybe not overcomplete things guys.

Having a recognizable URL on our website that points to the most up-to-date spec isn't a board matter.

having it updated, either manually or automatically, isn't either.

there's a lot that can be done with manual requests each year. If that starts to hurt, effort-wise, improvements will appear as by magic.

Guus: you are right, provided that "the most up-to-date spec" is a XEP

if "the most up-to-date spec" becomes a webpage, then process issues will arise.

also it looks like nobody PRed that redirect yet.

then make it be a pointer to the most-up-to-date XEP and be done with it.

heck, just copy the content in a new page for all I care.

Why isn't there a link to specs more prominently on the front page?

"the XSF periodically publishes a compliancy suite that blablabh. Here's the most up-to-date version!"

Guus: that's exactly what I suggested above ;)

@zash I agree that there's room for improvement there.

https://xmpp.org/extensions/ does mention the CSes at least

Ge0rG to quote a sneaker brand: just do it? ✏

Guus: because editing the web page is a bottomless pit

that page needs to be linked from somewhere.

and somewhere is probably XMPP/Overview, which is https://xmpp.org/about/technology-overview.html and where I don't even know where to start

and maybe https://xmpp.org/about/standards-process.html

None of this is a matter of procedure or bureaucracy.

but people want to make it a matter of procedure or bureaucracy because they don't understand our procedure and bureaucracy.

hm. the links in the "about xmpp" dropdown don't work for me any more.

anyway, I have no idea where to link that hypothetical new page from, so I give up.

I would do more of this page maintenance work if I could build the page locally without all that containerization. I did a PR to fix the 'menu missing' issue for current Pelican versions (which is the only blocking issue which keeps us from using an up-to-date Pelican version, I think).

wurstsalat: Are you saying that the `make` commands don't work?

If you don't pin to pelican 3.x (I don't remember) you end up with a missing main menu

(Which said PR fixes, but that won't run on old Pelican versions)

> or maybe create a small page that describes what the CS is about and links to all the versions? > that would be an improvement that can be implemented immediately! And you could look up older versions instead of the only being forwarded to the latest. If someone goes to that page to look up the version from two years ago because he wants to know what a specific clients support being forwarded to the current one would be annoying.