/me points at dwd What he said. On Fri, 21 Dec 2018 at 10:11, Dave Cridland <[email protected]> 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 <[email protected]> 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 <see-other-host/> 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 over the current status quo) >> Dave: +1 >> Jonas: +1 >> Kev: [pending] >> >> *3) Outstanding Votes* >> Everyone but Dave owes a vote on Proposed XMPP Extension: Simple Buttons >> - https://xmpp.org/extensions/inbox/buttons.html. >> Georg is still on-list; Jonas is going to read through the arguments and >> vote on-list. >> >> *4) AOB* >> Jonas is going to delay re-issuing the LCs from previous Council until >> next year, as it would be a wasted effort to do so now. >> >> Dave noticed that Jonas pushed through XEP-0412 (XMPP Compliance Suites >> 2019) before all votes have been made, and has literally no idea what do to >> about it as there is no process to handle a process violation. Jonas >> suggests reverting the changes in Git; Georg suggests pretending it never >> happened unless the final vote contradicts, and revert if so. Dave thinks >> reverting would be a bad idea as it could lead to 0412 referring to a >> different XEP. >> Kev makes a well-timed appearance and thinks everyone should Keep Calm >> and Carry On, and hope that Kev doesn't vote -1, but panic if he does. >> Dave thinks this is a process violation and should be flagged with Board >> - in their role as Guardians of the Process they should decide what is to >> be done. Jonas drafts an item for Board's Trello. >> >> *5) Next Meeting* >> Everyone agrees to skip next week as it would land the day after Jingle >> Tuesday, so the next meeting will be in two weeks. >> >> 2019-01-02 1600 UTC >> >> *6) Close* >> Thanks all! >> >> _______________________________________________ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
