[Standards] Council Voting Summary 2018-12-21
Let's try this and see if it helps keep things clear; also, treat it as prodding to get votes completed before they expire. Reply with corrections and/or omissions (actual votes should still go in their appropriate threads.) (I should add that I had been considering doing this for a while, and it bears no relation to a recent mishap - the timing is coincidental.) 2018-12-12 (expiring 2018-12-26) Proposed XMPP Extension: Simple Buttons - https://xmpp.org/extensions/inbox/buttons.html Dave: +0 Georg: -0 (data forms/ad-hoc commands elephant in the room; would rather fix i18n in data-forms) Jonas: +0 (could easily become a second XEP-0004 when people demand more features; provides something usable which might give good UX in simple cases) Kev: [pending] (concerned people will jump on this, implement the simple stuff, then start extending with other form fields, and we'll rebuild xep4) Link: [pending] Proposed XMPP Extension: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/inbox/cs-2019.html Dave: +1 Georg: +1 Jonas: +1 Kev: [pending] Link: +1 2018-12-19 (expiring 2019-01-02) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) - https://xmpp.org/extensions/xep-0410.html Dave: +1 Georg: +1 (obviously) Jonas: +1 Kev: [pending] Link: +1 (been testing an implementation and it did improve things greatly over the current status quo) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Simple Buttons
* Kim Alvefur [2018-12-08 20:01]: > Anyways, if clicking a button sends an exact string given on the button > then there should be no ambiguity? This is the second issue I have with this proto-XEP, because the i18n fails when clicking the button. You click "Ja" but your client sends "yes". This might be solvable by encouraging the implementations to mirror all labels from a button in respective i18n'ed elements, and by changing the examples accordingly. My primary issue, however, is the already discussed Data Forms / ad-hoc commands elephant in the room. I'd really like to see a strawman proto-XEP implementing the same functionality on top of data-forms in messages, just to be able to compare the relative scariness. What I like about this one is the apparent simplicity, but the question of when to show buttons and how to handle "race conditions" seems rather complex. * Matthew Wild [2018-12-09 11:50]: > I don't know of a single mobile client with dataform rendering for > example (so they don't do custom IBR forms, they don't do ad-hoc > commands, and they certainly won't do forms inside messages). As a mobile client author, I see the complexity, but having a mechanism to implement polls, buttons and the like (and to fix IBR on the way) this would actually be a motivation for me to finally tackle data forms! With all this considered, I'm -0 on the proto-XEP. If we can fix i18n in data-forms, I'd rather go the more-complex but more-flexible route. If somebody comes up with a proto-XEP for data-forms-in-messages and that actually does look frightening to me, I'll +1 this one based on KISS. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Simple Buttons
So a few weeks have passed, and I’m still torn. Last week’s council meeting has brought some discussion [1]. I think Kevin brings up the important point that this could easily become a second XEP-0004 when people demand more features (which this XEP will have trouble to deliver). However, for now, I think it provides us with something usable which might give some good UX in simple cases. I am +0 on this. kind regards, Jonas [1]: http://logs.xmpp.org/council/2018-12-12#16:04:45 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-12-19
/me points at dwd What he said. On Fri, 21 Dec 2018 at 10:11, Dave Cridland wrote: > Hi folks, > > There were two heavy chunks of "Process" in this meeting. Surprisingly, I > hate process - as anyone I've worked with can attest - but I'm usually the > one defending it, so here I go again. > > The reason we have a process is not to make our lives more difficult, but > to make everyone's lives - particularly participants' - easier. With a > typical open source project on Github, there's so much tooling around the > process people often think it doesn't exist, but there usually is some > process. A contributor comes along and suggests a change, it's reviewed by > the maintainers, and if approved, it's merged. If a new contributor turns > up and sees a project hosted on Github, they know roughly how things are > going to work. > > That's kind of what we have, except the "people who merge", and the > "people who review" are different - they're the "XMPP Extensions Editor" > and the "XMPP Council" respectively a lot of the time - for experimental > XEPs, or process XEPs, it's different. When it's different is covered by > XEP-0001, and what changes can be approved is also covered by XEP-0001. > That is, in a nutshell, our process. > > But the idea is that a new participant in our standards ought to be able > to read XEP-0001, and from that gain a set of expectations on how to > contribute to documents and what will happen. Moreover, if Council (for > example) do not follow this, they can be called out on it. Every now and > then, people do try to insist that the XSF does something unusual with > their favourite document, for reasons ranging from commercial > considerations to deciding they want the document moved to another > Standards Development Org that will do what they want. Having a defined > process means both that the Council has a simple defence here, and that all > the other participants - and that's you, if you're reading this - aren't > going to be taken by surprise. > > That is not to say that our process is either perfect, nor immutable. I > find it as irritating as anyone else when we find ourselves trapped by the > process, or having to jump through hoops in order to satisfy it. Process > should not be a stick with which to beat people. Our process should simply > describe what we do - so sticking to it should be easy. If we can improve > it, we should do so, and anyone - XSF Member or not - can suggest process > improvements (such as simplifications), and ask the Board to approve them. > > So, "We'd like to move a XEP from Deferred to Obsolete" is not a > suggestion that is intrinsically wrong, but one we cannot do. But if (in > this case) Emmanuel wants this to be possible, it's possible to change > things so we can. We've changed it recently for largely similar things. > > On the other hand, Jonas's slip-up can be resolved. In this case, Council > were generally not worried, and offered a suggestion to Board. Board > rejected it, and have insisted on a different resolution. And I'm delighted > with the way this has worked out, even though Board disagreed with what > Council (including myself) wanted to do. > > The real test of openness, fairness, and transparency in an organisation > is when things go wrong. In this case - and many thanks to Jonas for > providing the opportunity - I'm very comfortable that we passed that test. > > Dave. > > On Thu, 20 Dec 2018 at 20:27, Tedd Sterr wrote: > >> http://logs.xmpp.org/council/2018-12-19/#16:00:41 >> >> *1) Who's Here?* >> Present: Jonas, Georg, Dave, Link >> Fashionably late: Kev >> >> Dave asks if there is anything new to vote on - Jonas points to PR #727 ( >> https://github.com/xsf/xeps/pull/727); Georg would like to ask for an LC >> on XEP-0410. >> >> [PR #727 moves three XEPs from Deferred to Obsolete, as they were >> deferred long ago and appear to be no longer useful.] >> Jonas thinks XEP-0008 should be made Active (it's historical), and >> XEP-0051 can be obsoleted with a reference to the stream >> error, but has no idea about XEP-0038. >> Dave doesn't think XEPs can be moved from Deferred to Obsolete; Jonas >> concurs. >> Link suggests skipping a few states in the path to Obsolete for XEPs that >> will obviously no longer be needed; Dave says it would be possible to do: >> Deferred → Experimental → Proposed → Rejected, with a well-placed Last Call. >> Dave asks what Link is actually trying to achieve, and why Deferred is >> not good enough - Link would like to sort the deferred XEPs into "no longer >> needed" and "should be LC-ed"; Jonas likes that plan. >> Link would like to eventually deprecate the Obsolete state; Dave says the >> point of the state is to de-clutter Experimental. Jonas suggests focusing >> more on saving those that might be useful. >> Dave concludes that current process doesn't allow for this, and is >> therefore not keen on voting on it. Link queries escalating the matter to >> Board - Dave suggests putting it to
Re: [Standards] XMPP Council Minutes 2018-12-19
Hi folks, There were two heavy chunks of "Process" in this meeting. Surprisingly, I hate process - as anyone I've worked with can attest - but I'm usually the one defending it, so here I go again. The reason we have a process is not to make our lives more difficult, but to make everyone's lives - particularly participants' - easier. With a typical open source project on Github, there's so much tooling around the process people often think it doesn't exist, but there usually is some process. A contributor comes along and suggests a change, it's reviewed by the maintainers, and if approved, it's merged. If a new contributor turns up and sees a project hosted on Github, they know roughly how things are going to work. That's kind of what we have, except the "people who merge", and the "people who review" are different - they're the "XMPP Extensions Editor" and the "XMPP Council" respectively a lot of the time - for experimental XEPs, or process XEPs, it's different. When it's different is covered by XEP-0001, and what changes can be approved is also covered by XEP-0001. That is, in a nutshell, our process. But the idea is that a new participant in our standards ought to be able to read XEP-0001, and from that gain a set of expectations on how to contribute to documents and what will happen. Moreover, if Council (for example) do not follow this, they can be called out on it. Every now and then, people do try to insist that the XSF does something unusual with their favourite document, for reasons ranging from commercial considerations to deciding they want the document moved to another Standards Development Org that will do what they want. Having a defined process means both that the Council has a simple defence here, and that all the other participants - and that's you, if you're reading this - aren't going to be taken by surprise. That is not to say that our process is either perfect, nor immutable. I find it as irritating as anyone else when we find ourselves trapped by the process, or having to jump through hoops in order to satisfy it. Process should not be a stick with which to beat people. Our process should simply describe what we do - so sticking to it should be easy. If we can improve it, we should do so, and anyone - XSF Member or not - can suggest process improvements (such as simplifications), and ask the Board to approve them. So, "We'd like to move a XEP from Deferred to Obsolete" is not a suggestion that is intrinsically wrong, but one we cannot do. But if (in this case) Emmanuel wants this to be possible, it's possible to change things so we can. We've changed it recently for largely similar things. On the other hand, Jonas's slip-up can be resolved. In this case, Council were generally not worried, and offered a suggestion to Board. Board rejected it, and have insisted on a different resolution. And I'm delighted with the way this has worked out, even though Board disagreed with what Council (including myself) wanted to do. The real test of openness, fairness, and transparency in an organisation is when things go wrong. In this case - and many thanks to Jonas for providing the opportunity - I'm very comfortable that we passed that test. Dave. On Thu, 20 Dec 2018 at 20:27, Tedd Sterr wrote: > http://logs.xmpp.org/council/2018-12-19/#16:00:41 > > *1) Who's Here?* > Present: Jonas, Georg, Dave, Link > Fashionably late: Kev > > Dave asks if there is anything new to vote on - Jonas points to PR #727 ( > https://github.com/xsf/xeps/pull/727); Georg would like to ask for an LC > on XEP-0410. > > [PR #727 moves three XEPs from Deferred to Obsolete, as they were deferred > long ago and appear to be no longer useful.] > Jonas thinks XEP-0008 should be made Active (it's historical), and > XEP-0051 can be obsoleted with a reference to the stream > error, but has no idea about XEP-0038. > Dave doesn't think XEPs can be moved from Deferred to Obsolete; Jonas > concurs. > Link suggests skipping a few states in the path to Obsolete for XEPs that > will obviously no longer be needed; Dave says it would be possible to do: > Deferred → Experimental → Proposed → Rejected, with a well-placed Last Call. > Dave asks what Link is actually trying to achieve, and why Deferred is not > good enough - Link would like to sort the deferred XEPs into "no longer > needed" and "should be LC-ed"; Jonas likes that plan. > Link would like to eventually deprecate the Obsolete state; Dave says the > point of the state is to de-clutter Experimental. Jonas suggests focusing > more on saving those that might be useful. > Dave concludes that current process doesn't allow for this, and is > therefore not keen on voting on it. Link queries escalating the matter to > Board - Dave suggests putting it to The List. > > *2) Last Call: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))* - > https://xmpp.org/extensions/xep-0410.html > Georg: +1 (obviously) > Link: +1 (been testing an implementation and it did improve things greatly >
Re: [Standards] NEW: XEP-0412 (XMPP Compliance Suites 2019)
Hi Jonas, To clarify: - There is absolutely no indication that anyone tried to pressure anyone into doing anything. Board's comment can be seen as to wanting to prevent such leverage to become possible in the future, by establishing a precedent of keeping prematurely published XEPS published. - Board had another reason for wanting the prematurely published XEP to be retracted: by publishing a XEP, the XSF might (or even: "intends to") trigger third parties to start spending resources (on implementing the XEP). When a XEP is published by mistake, it is therefor important to reduce the risk of more people starting to base work off of it, by retracting it as soon as possible. Thank you for flagging this, and act swiftly to rectify. Mistakes happen. It's how they're followed up on that characterizes them. Regards, Guus On Thu, 20 Dec 2018 at 17:37, Dave Cridland wrote: > Hi Jonas, > > Thanks for sorting this out, and my apologies for the formal process hoops > to jump through. > > I'm amazed this has never happened before, actually. > > Dave. > > On Thu, 20 Dec 2018 at 16:13, Jonas Schäfer wrote: > >> Hi list, >> >> >> I published this specification (XEP-0412) ahead of time. The vote of >> council >> (which I am embarrassingly part of) has not yet completed. >> >> While the stance of Council (including the member who hasn’t voted yet >> and me) >> on this matter was to wait it out and deal with the issue of retraction >> should >> the vote be a -1, the Board has decided to prevent to set a precedent by >> the >> premature publication, which could be used by the Editor to exert >> pressure on >> the not-yet-voted Council members. >> >> I personally fully support the decision of the Board. >> >> I understand the delicacy of the situation especially since in this play, >> I’m >> both the Editor *and* the Author of the specification; I do not want to >> be >> seen as someone who would abuse any role like that, so I’m happy to >> execute >> the Board’s ruling. >> >> I’d also like to sincerely apologize especially to Kev whose vote I have >> forgotten (actually I was 100% sure that everyone had voted, and only >> while >> checking results for other votes I came across the "on list" from Kev :() >> and >> to the community for the extra noise and possible temporary confusion and >> misguidance due to the published compliance suites you had to endure. I’d >> also >> like to apologize for not bringing this matter up to Board immediately. >> >> The specification has been un-published and replaced with a tombstone XEP >> (the >> build is still in progress; the website will thus be updated shortly). It >> will >> stay a tombstone should Kevin decide to vote -1, and it will be replaced >> with >> the actual XEP again should Kevin decide to vote 1 or 0. >> >> >> kind regards, >> Jonas___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ >> > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
