Dave Cridland for Council 2019
Hi, I'm Dave. I've been on Council for several sessions (including the last, erm, three years, I think). I have chaired the last two. There's more info at My user page.
... Does the Council do? The XMPP Council is the final gatekeeper for specifications we produce. It votes, and its members have vetos, over various stages in a specification's lifecycle.
That's all that XEP-0001 says, really, and our bylaws only describe how we're elected, so they're not much use either.
In reality, though, I think the Council is best described as being a small team entrusted by the community to ensure that the specifications we produce are the very best they can be. This means that the Council needs to understand the compromises and considerations those actually producing the specifications encountered as they worked on it, and also that the Council needs to be able to see what considerations those writing the specification failed to take into account.
When one phrases the task the Council faces in this way, it sounds like the Council are apart from the community "doing the work". The community writes specifications, and then an entirely distinct set of people check them over. That's both right and wrong - the individuals on the Council are, of course, part of the community themselves, but the Council acts as a distinct unit. This is important, because it explains why people on the Council can write a specification, yet have it rejected by the Council - sometimes due to votes they themselves put in. I know I've vetoed my own specification before, and I'm not the only one.
What the Council doesn't do is, well, many things.
It doesn't create new specifications.
It doesn't do protocol design work.
It doesn't offer much in the way of explanations of how to get a specification through - just explains why it was rejected.
So, as chair of the last council session, I think I'm comfortable saying what it got wrong.
As I note in my Board application, some of this is due to Council's visibility of the discussion around specifications. This means we're no longer aware of the compromises made, nor the rationale behind design decisions - and that makes things harder for us. It also means specifications can get rejected because they didn't meet considerations that the authors were unaware of. This is disheartening for authors, frustrating for Council, and cannot possibly yield good results for the community.
Also, we've had a continuation (and, I think, worsening) of votes taking a lot longer than they should. The Council voting isn't the longest phase of standards development, of course, but it's an entirely blocking period. Literally nothing can happen during it.
This latter is certainly my fault as chair. I was hoping I could avoid this with some tooling, but that didn't work out, and I didn't maintain the voting spreadsheet from the year before.
Finally, I was pretty poor about getting the Agenda out on time, making it difficult for other Council members to know what they'd be voting on, and making the above situation worse. In my defence, I changed jobs twice over the past 12 months, but that's an explanation and not an excuse.
As such, I'm not intending to stand for Chair this year. If I get elected to Board, I'll decline any nomination, otherwise I'll encourage someone else to do it (with the caveat that if nobody else feels up to the task of creating an agenda consistently, and tracking/chasing voting, then I'll give it another go under some protest).