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 <teddst...@outlook.com> 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: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
