On 19 Jan 2018, at 13:58, Stefan Haun <[email protected]> wrote: >> While the >> previous Council failed to get this to vote despite a long period of >> Sam trying, > > In my view, this is the key reason for being in the current situation. > Was this failure to get the vote in time addressed or taken into account?
It was, in as much as that’s what automatically triggered the new Last Call, and one of the reasons I submitted a PR addressing my comments, so that Sam didn’t have to do additional work on it. > Did somebody apologize for delaying the vote or making Sam miss the > end-of-2017-deadline? I wasn’t involved in the previous Council, I wouldn’t know. >> Sadly, the current course of action isn’t Council’s, but Sam’s. > > So the council has no leadership role in the XSF? It does, but that doesn’t mean it should take actions on behalf of active Authors unless absolutely needed (Council could have removed Sam as Author and got someone new there, but I don’t think that would be appropriate here (and given Sam’s role on Council also unlikely to happen)). >> In the general case, it is very dangerous for Council members to feel >> that they are not able to give feedback, or expect it to be addressed >> - in a discussion a little while ago on-list, Sam agreed here that >> Council should give their feedback. > > But this is not a general case. Previous Council failed a process (by not > voting in time) and current Council tries to heal this by pressing on with > the correct process. Right, we have a procedure in xep1 exactly for this, which the XEP Editors (rather than Council, technically) followed by starting a new Last Call when Council terms changed over. But beneath that we have a situation where Council did a review of the XEP before voting, and the Author didn’t address feedback. While both are true that no one instance is the general case, and that I’m no fan of slippery-slope arguments, that is not a desirable situation to be in. >> Sam has chosen to step back from the suites, and there’s not a lot we >> can do to force him to continue with them (nor should we), although >> for my part I’d be very happy if he changed his mind. > > There was a window of opportunity to resolve the issues and motivate him to > continue. > (Again, my view.) There was. And sending feedback long before the vote, and sorting out the changes myself so there was no work for Sam to do here was meant to help this. > >> I have been trying for some weeks. I now realise that all the >> discussions trying to resolve this have happened in the Council MUC >> (the logs for which are available, but I doubt anyone has any >> inclination to sift through them), which makes it seem to anyone not >> following the events that this has come out of the blue, but it would >> be a mistake to believe that to be the case. > > I take from this answer that any further analysis would indeed need somebody > to sift through the protocol. > I've just been provided with this pointer: > https://mail.jabber.org/pipermail/standards/2017-December/034002.html > (This mail alone is not enough, though I see a deadline mid November which > was missed?) I particularly meant the MUC logs, like http://logs.xmpp.org/council/2018-01-10/#18:54:43 - but unfortunately these days we’ve got discussions going across multiple MUCs (particularly xsf@ and council@, but rarely also jdev@), as well as the mailing lists, so it’s very hard to keep up with everything. The most critical stuff goes to list, but the incremental negotiations and compromise attempts are often not recorded there. > Again: The whole thing has become a strategic question. If the Council comes > to the conclusion that sticking to the process is better than resolving the > issue in Sam's favour (there are good arguments for both) That’s a false dichotomy. "resolving the issue in Sam's favour” here was getting the XEP advanced, and we had a path where exactly that was possible this week. Things have clearly gone wrong here, but I don’t think ‘sticking to process’ is the cause. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
