jonas’nice, now the work laptop is playing a snippet of metal in a very tight loop
jonas’trying suspend-then-hibernate wasn’t a good plan
jonas’ok, with that disturbance out of the way...
jonas’3) Editor’s Update
jonas’- XEP-0045 v1.33.0 which removes 307 status code from service-caused kicks (as opposed to moderation-caused kicks)
jonas’4) Items for Voting
jonas’4a) Discuss whether PR#971 was rejected on false premises
Sorry for this one. Flow brought up -- correctly -- that type="cancel" is special and we should discuss real quick if that changes anything for the folks who vetoed.
jonas’since XEP-0004 states:
> a data form of type "cancel" SHOULD NOT contain any <field/> elements.
I think some of the arguments in my original email regarding this topic may be invalid
jonas’since others based their vote on those arguments, please reconsider
jonas’and let me know if we should re-vote on this one
ZashI'm staring at a diff right now .
Ge0rGI'm still unconvinced whether removing text adds clarity.
ZashSo.
jonas’trivial example of where removing text adds clarity:
> The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types.
vs.
> "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W and X.✎
jonas’trivial example of where removing text adds clarity:
> The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types.
vs.
> "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W only. ✏
jonas’or something similar, you get the gist :)
danielI'll read this again
danielThe diff format with extremely long lines also makes this super hard to read
Ge0rGjonas’: so the answer to your question is probably: we should re-vote #971
jonas’re-writing my email from back then, I arrive at:
Let me break this change down using the word diff (attached: ab.wdiff, pipe it
through colordiff(1) for best viewing).
Before:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit": @type MAY, absent assumes available context(*)
- type="result": @type MAY, absent undefined
- type="error": SHOULD NOT have any fields, @type MAY
After:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit", type="result": @type MAY, absent assumes available context(*)
- type="error": SHOULD NOT have any fields, @type MAY
(*): It is assumed that the recipient of the form has enough context to infer
the @type value. Bad design IMO, but we’re stuck with that.
So while the PR reduces the amount of text, it introduces undefined behaviour
for @type="error", which I don’t endorse.
✎
jonas’re-writing my email from back then, I arrive at:
Let me break this change down using the word diff (attached: ab.wdiff, pipe it
through colordiff(1) for best viewing).
Before:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit": @type MAY, absent assumes available context(*)
- type="result": @type MAY, absent undefined
- type="error": SHOULD NOT have any fields, @type undefined
After:
- type="form": @type SHOULD, absent implies "text-single"
- type="submit", type="result": @type MAY, absent assumes available context(*)
- type="error": SHOULD NOT have any fields, @type MAY
(*): It is assumed that the recipient of the form has enough context to infer
the @type value. Bad design IMO, but we’re stuck with that.
So while the PR reduces the amount of text, it introduces undefined behaviour
for @type="error", which I don’t endorse.
✏
jonas’and I think I prefer that a lot and would also suggest to re-vote
jonas’daniel, hence wdiff + colordiff
Zash+ aha | htmlpaste
jonas’:)
jonas’I’m still in favour of my patch though, because that handles the case where an entity violates the SHOULD NOT for type="error" and clearly spells out what’s going on
jonas’I guess I’ll propose my patch as separate PR and then we can vote on both?
danielSounds good
Ge0rGjonas’: great
ZashSure
Ge0rGand maybe Zash can provide a rendered html-diff of it ;)
dwdhas joined
jonas’https://github.com/xsf/xeps/pull/975
dwdGah. Afternoon, sorry for being late.
jonas’oh great, dwd
jonas’I suppose you’ll have strong opinions regarding how we should handle Process here
Ge0rGjonas’: is there really Process for bringing up the same PR again?
jonas’Ge0rG, probably not written down, but dwd still might have a valuable opinion on that :)
Ge0rGZash: it is HTML, but it's not HTML.
jonas’Zash, those \" make it harder to read :/
dwdPRs are nothing but a convenient way to give things to Council, I don';t think there's anything preventing us using the same one twice is there?
Zashpandoc does that
jonas’dwd, no, it’s about re-voting on the same thing after council pretty clearly vetoed it before
jonas’Zash, can you do the diff on the xml instead of whatever pandoc did there?
jonas’I think the colour-coding would already hep✎
jonas’I think the colour-coding would already help ✏
dwdAh. So there's nothing that prevents us doing so, but unless new things have come to light I feel a little concerned about doing that.
jonas’(hoping that none of us has red-green-weakness)
Ge0rGdwd: new things like the realization that the first voting Member was wrong, and the other ones just copy&pasted the rationale?
jonas’dwd, I expected as much. Do you think that new things did indeed come to light based on what I wrote earlier (in the agenda announcement and above, I shall quote from above):
since XEP-0004 states:
> a data form of type "cancel" SHOULD NOT contain any <field/> elements.
I think some of the arguments in my original email regarding this topic may be invalid
since others based their vote on those arguments, please reconsider
jonas’or as Ge0rG put it, indeed
Zashjonas’: Main difference is extra noise and lack of line breaks in paragraphs.
Ge0rGjonas’: I really like your wording as displayed by Zash's colored "html" version
jonas’that’s not my wording tho?
jonas’that’s flows wording
ZashThat wasn't jonas’
dwdGe0rG, Well, there's a good argument to avoid "me too" veto votes, of course. :-)
Ge0rGdwd: yes, I'm guilty of that. But the rationale that was provided really sounded convincing back then!
jonas’it’s easy to construct convincing-sounding rationales for '4, '45 and '60.
jonas’(and probably '369 et al. too)
Ge0rGwhoops.
jonas’though I’ll clearly state that this was not my intention and I simply wasn’t aware of the type="cancel" specialcasing
Ge0rGSo I really like flow's wording then. Can we also get a pr975.html, please? Zash?
dwdI like the table. ISTR I was on-list because I was confused about what the wording used to say and what it now says, which at the very least suggests that the wording needs improvement.
jonas’we’re close to the end of the meeting and everyone is confused
dwdBut if I understand correctly, we're happy about the intent in flow's PR, just not so much about the wording?
jonas’I am
jonas’as I said in my original email
jonas’I take that we should re-vote on PR#971 and/or PR#975 next week. Please read carefully everyone, I’ll update PR#975 with a more major reformatting after this meeting (taking the suggestion to pull my "table" from the email into the document)
dwd+1. Having (a) moved my XMPP server to AWS off the machine that was failing, and (b) moved DNS to a machine with IPv4, I might even be able to join properly.
