XSF Discussion - 2019-06-13

MattJ: given the regrets sent, what if we use the Board timeslot for discussing infra in the other place? (cc Seve)

Sounds good

Ok

hey found some errors in the MUC xep

impossible

https://xmpp.org/extensions/xep-0045.html#example10 muc#roominfo_changesubject is twice in the disco info

and then i looked up muc#roominfo_changesubject and it is not in the registry for muc#roominfo

there is though another value that muc#roominfo_subjectmod

the registries are stale

but we have now two values that do the same thing

one in a example which are not normativ

Mistakes in examples are easy to fix at least 😉

Zash can you lookup if prosody implements the correct one?

The correct what?

muc#roominfo_subjectmod (in registry) vs muc#roominfo_changesubject (in examples)

https://hg.prosody.im/trunk/file/0.11.2/plugins/muc/subject.lib.lua#l32

yeah that seems to be the false one

Do you want me to create an issue?

The one mentioned in multiple places in the XEP?

lovetox, funny thing is, we added this for you :) https://issues.prosody.im/1155

haha yes, and i copied it from the example 😃

Zash actually its only mentioned in one place in the XEP, exactly in this wrong example

i think the confusion comes from muc#roomconfig_changesubject (config not info)

which is valid in room config forms

> Zash> Mistakes in examples are easy to fix at least I tried once to fix non compliant examples but council decided to go with broken examples

Or fix the registry. `muc#roominfo_changesubject` seems to have become the de-facto standard 🙂

flow, are you confusing "broken" with "noise-reduced examples"?

or which instance are you talking about?

jonas’, broken as in "if an entity would send such an stanza that it would violate the spec"

if noise is really an issue here, which I doubt, then at least mark the examples as incomplete

flow, IIRC somebody stood up to do exactly that

it might’ve been me

(with <!-- ... --> markers) ✏

dunno, xml comments are also invalid in xmpp, and what's the difference between adding a single line of "here is something missing" markers and a single line of what is actually missing

flow, it’s more than a single line because a MUC service also has to implement disco#items

so you need at least two lines

XML comments being illegal in XMPP makes it very obvious that this is a meta-marker, which is great

Fair point, so two lines, I still don't see a noise problem. I guess what bothers me most is that many solutions for issues are rejected by council, because council has a, in their opinion, better solution, but that never materializes…

that’s a fair criticism

Especially in this case the first solution could have just been merged and then changed later on

that’s probably also fair

I always wonder what we can do about that. For things which are considered a defect by consensus, requiring the vetoing council members to provide a counter proposal within a reasonable timefrime could be one approach

But you can easily get gridlock'ed if those counter propsals are also vetoed

OTOH that is the state we currently have

"requiring" anyone to do anything in a volunteer organization is hard

although one could say that the veto is reverted if no counter proposal is made within that timeframe.

jonas’, that is exaclty the incentive I had in mind

and there’s also different kinds of defects

or situatinos

flow, would you mind proposing that mode of operation in the next council meeting?

I think that might be a good thing to have

I have in mind to make it optional on the veto-ing side, i.e. the veto-er who wants to make a better version essentially says "-1 if I can make a counter proposal within 2w, otherwise +0" or something

we’d have to figure out if that works with the bylaws and such

jonas’, I'll put in on my TODO list

Currently the requirement for a veto is that the vetoing member explains what's required to remove the veto.

Which seems like the best option available at the moment.

But there's nothing stopping someone who vetos doing as jonas’ says and saying "Veto unless I don't get a patch out".

don’t the bylaws give us a voting timefrmae?

Is the voting period relevant to this?

maybe

you may be effectively changing your vote after the voting period

I don't think anyone cares, if done sensibly.

Because all it's doing is being functionally equivalent to everyone voting early on a future-scheduled item.

So whats the way to go for the MUC XEP problem?

should we fix the example

or the registry?

registry obviously nicer, but is it possible?

lovetox, could you give a brief summary of the MUC XEP problem?

its in the muc log starting at 16:05

bascially every server impl took muc#roominfo_changesubject from a wrong example

this value is not in the registry

in the registry there is muc#roominfo_subjectmod

and both carry the same semantics? And the XEP has no normative text about this?

is the registry not normativ?

I'd say so

muc#roominfo_changesubject is only present in one example

So choose one and add a text to the XEP that it is recommended that services also support the other value?

Probably including a sentence or two about the situation

yeah we were at that point, just not sure which

add the one everyone uses to the registry

or remove the one everyone uses from the example

question is can the registry just be extended easily?

the one everyone uses is not the one in the registry I assume?

yes

we could just extend the registry and be fine

I don't see an issue why we shouldn't go with it then, and change the registry entry