User:Dwd/Council 2020

Council Criteria

I'm Dave Cridland. I have worked on clients (mostly hacking together scripts, in fairness, but a little bit of Gajim work in my deep past - I've more experience in writing email clients actually). I have worked on servers (M-Link, Openfire, Metre, lots of bespoke, but I also know my way around MongooseIM and Prosody's codebases if needs be). I'm pretty sure I have a commit or two in Smack, and certainly chunks of Sleek/Slixmpp, too. This experience gives me a pretty good idea of what designs of protocols are generally efficient and easy to implement in different servers.

I have served on the Council itself several times, including chairing it. This gives me a pretty good idea of what works, and what doesn't, for Council.

I've written lots of XEPs, many of which people have actually implemented and thought were OK. Some of which have died by the wayside - I have rejected my own ProtoXEPs more, I think, than any other author (except maybe Peter). I've had XEPs rejected when I've not been on Council, too.

I've never really worked in "consumer messaging", though I've obviously used consumer messaging tools. Most of my experience has been on closed networks, used for military, healthcare, and similar critical spaces. I think this is a valuable and useful viewpoint, though obviously not an overwhelming one.

Voting Record

The Council Spreadsheet of Doom

Pandemic

So, I had a busy pandemic, in as much as in my day job, Pando, we provide "clinical messaging" to a largish chunk of the NHS in the UK, and usage went ballistic during April/May in particular. So suddenly, I got really into scaling a service so Doctors and Nurses could coordinate the medical response, and didn't have time for several weeks for Council activity. I would apologise, but I reckon that's a pretty good excuse and anyone in the same position would have prioritised accordingly, and my voting was (surprisingly to me) largely unaffected.

On the other hand, for most of July I still was busy enough not to fix the hardware problems in my XMPP server, and so that really messed me about. Sorry about that.

What does Council do?

Council, more or less, judges community consensus on advancement questions, ensures the criteria for XEPs are met, does some quality control and applies personal judgement around the overall "architecture" of XMPP. Nearly all of these conflict with each other on multiple occasions, and most have no written rules.

But Council does unequivocally represent the review of last resort - Council is the final gatekeeper of our specifications. So it's fitting that it's not a mere robotic test of criteria, but something that requires human judgement and opinion. Otherwise we'd just replace it with an automated test suite.

ProtoXEP adoption criteria

When a protoXEP is submitted, it's an intensely personal moment for the author. Broadly, I'd rather adopt a new XEP than reject it. As long as I can understand what the problem is that the author is trying to solve, and broadly the direction they want to take, I'll almost certainly accept it. I only vetoed one ProtoXEP last session, and I later voted to adopt it unchanged.

I do accept them on the basis that they will then follow community consensus in their development, and are no longer "owned" in any sense by their authors, though. That consensus isn't a measurement of the loudest voices, either, but an understanding of where the common ground is (or might be).

Advancement Criteria

I'm more strict on advancing votes. To my surprise, I've voted against a lot of these this session. There's a lot of reasons for this, but a common one is that nobody seems very interested. It's pretty disconcerting to wave through a XEP that hasn't had any Last Call comments.

I do vote every XEP through to Last Call, though - I have no idea why Council even has to do that, but maybe there's some reason I'll stumble onto why it's a bad idea to do a Last Call one day.

Other Goals

Council is, essentially, reactive - it's up to all of the community to propose new XEPs, update existing ones, and push for advancement. So whether or not I'm on Council, I'll try to do that, as we all should.

But the Council is - sort of - the technical leadership of the community, so it's fair to say the Council should lead by example as well, and put a bit of direction and effort into strategic areas. So:

Platform vs Solution

One area I do think we'll need to pay attention to is the distinction between a "Platform" and a "Solution". Sometimes, we look at XMPP as a monolith, albeit one made up of little atomic XEPs, that one implements as a whole, and the output is an Instant Messaging system. That's what I mean by "Solution". Our Compliance suites, for example, are very much in this mould. It's a perfectly sensible thing to be, and we should definitely continue to support this path. It's the route that a lot of the community building clients (and many building servers) are most interested in.

The other side of the coin is to be a Platform - something people take and build their own things on top of. While it's less visible and exciting, XMPP has a vast amount more traction here. This is the land of NATO, Nintendo, Zoom, and Eve Online. I think it's equally valid, and possibly more exciting in a lot of ways, but as a community I think we're interested in this less, and correspondingly put less effort in. That's not wrong - we are volunteers, and ideally these people would show up and join in. But strangely, we're missing the platform builders from the Open Source world, perhaps because we just don't focus on this as a community. If we want to make life better for Platform builders, and make XMPP more of a natural choice, I think we need to put a bit of effort in here.

Pragmatic Apple Support

Obviously all Apple stuff sucks. And yet, it's extraordinarily popular. Therefore, we should seek to understand, and weigh highly, the experiences of Apple developers working with XMPP, and ensure their challenges are well supported in both Platform and Solution. We need to ensure that Push, groupchat, and other common use cases in both Platform and Solution are easy and solid under iOS and OS X.

I'd like nothing more than to tell my Apple-using friends to use an XMPP client confidently, and while I think there's been movement toward that in recent years, it's just not fast enough for my liking, and I worry that's our fault as a community.

Council vs Board

I have things I want to do on both, but being on both Council and Board isn't ideal.

I'll review the state of applications, and if I feel I can I'll withdraw from one or other.