User:Jwi/Council 2020

This is my (Jonas Schäfer) application for the XMPP Council for the term 2020/21. The election page is at Board and Council Elections 2020.

Contact info / meta

I’m Jonas Schäfer. You can find me in XMPP related MUCs as jonas’, or can contact me via XMPP or email. More contact info and meta can be found on my user page.

I am currently employed as DevOps Engineer at CLOUD&HEAT Technologies GmbH.

This is my third application to the Council. You can look at my 2018 and 2019 applications.

Who am I / What are my qualifications?

• I served in Council for two terms, the last one as Chair.
• I have served as an Editor in the XSF for three years now. This has brought my attention to many parts of the XEP space and made me familiar with the XEP process itself.
• I am the main author of the aioxmpp XMPP library for Python. aioxmpp has been built from scratch (only on top of a SAX XML parser) and supports RFC 6120 through 6122, as well as many important XEPs, such as Stream Management. The process of writing this library has brought me close to the protocol and gave me lots of insights into the edge-cases. On top of that library, we’re working on a desktop XMPP-IM client.
• I am developing, hosting and maintaining the Public Chat Room search engine at search.jabber.network. This is a large-scale application interfacing with many different implementations (currently interfacing with 2130 domains), which has sharpened both aioxmpp and my sense for interoperability.
• I am also offering the free monitoring-as-a-service for XMPP operators at observe.jabber.network. This is a monitoring deployment where anyone can add their servers to receive emails in case they become unreachable from the internet and/or the federation. Including certificate expiry warnings.
• I am the author of three XEPs:
  1. XEP-0390 (Entity Capabilities 2.0): Replacement for XEP-0115 which fixes issues with hash agility, the insecure hash input generation and gives entities more power in caching disco#info responses. There is an implementation in aioxmpp (obviously :)), as well as an experimental implementation in prosody.
  2. XEP-0392 (Consistent Color Generation): Algorithm to generate a color value based on text; used to generate dummy avatars or color participants in a MUC. Has been deployed on Conversations, poezio and maybe others.
  3. XEP-0394 (Message Markup). Attempt to provide a replacement for the deprecated XHTML-IM. I gave this one up for someone else to fix.

Goals

Primary Goals

• Allow the Council to operate stably and stay on top of tasks and agenda. I liked the role as Chair and I’d be happy to continue it.

• Make our contribution process more inclusive, especially for new contributors. Mediation between authors and Council and other teams/bodies of the XSF is crucial to not lose talent and new interest in the protocol. I think we can still improve here by providing more guidance to new authors and be more inclusive in our meetings. In the past, I explicitly pinged people who were not in the room when their work was being discussed to allow for clearer communication.

Background Goals

• Make our specifications more useful to new and existing developers. This means in particular:
  • Ensure that identified edge-cases are well-defined in the specifications
  • Document and/or standardise workarounds for existing issues and extensions to existing protocols, even if those existing protocols are already in Draft state (looking at you, XEP-0045).

• Improve the modern IM use cases. This means in particular:
  • Work on solving the group chat use-cases. This means, among others, approving fixes and extensions to MUC, as well as monitoring and contributing to the development of MIX (which is still Experimental).
  • Work on multi-device use-cases: Drive and support the development of IM Routing NG (XEP-0409), as well as improvements regarding configuration sharing between clients and with the server (think notification preferences).
  • Take the different modern IM use-cases into account and consider how they interact and can be solved with our specifications. Some GNOME folks have used the terms Banquets vs. Barbecues for describing the two different flavors of group chats: anonymous, IRC-style, FLOSS-community chats (Banquets) and private, non-anonymous, family-type chats (Barbecues). There are implications in how to handle traffic for both of them w.r.t. notifications on the client, push and CSI. If XMPP is to cover both cases (and I think it should), we need to take those differences into account and make our specifications flexible enough.

My Role in Council (and evaluation of the past year)

So the past year was the first year serving as Council chair. This has forced me to introduce a routine where I take an hour or so the day before the meeting to prepare the agenda (and, while doing that, also process the editor queue, since those are directly linked). I think this was beneficial for many of my involvements with the XMPP community.

I also hope that I was able to fill the role of Chair in a way which was useful for the other Council members (I would like to thank Dave for the Spreadsheet of Doom and Tedd Sterr for the Minutes and some out-of-band messages which helped to keep track of things though!).

Aside from that, the same list as last year:

• Attend the meetings as reliably as possible: This has worked quite well in the past year. There have been occasions where I wasn’t able to attend, but most of them have been communicated well ahead of time and we found solutions for that.
• Judge contributions to XEPs where Council has to decide about the acceptance for the bettering of the protocol: I think this improved a lot compared to the previous year; relying on expertise of community members has been a good working method.
• Judge ProtoXEPs and vote for their acceptance if they are not harmful, have a goal which can be understood and do not duplicate existing protocol (with exceptions, e.g. accept two competing ideas to see their further development): I think I learnt a lot from the Reactions case here. I think we need to be less protective of Experimental and encourage, well, experimentation more.
• Comment on standards as they happen: I surely hope I voiced my opinion where I had something to contribute and shut up otherwise.
• Guide (new) contributors to XEPs in a way which is welcoming and avoids duplicate work (for example, make it clear politely when a contribution is going in a direction which is unlikely to be accepted by the Council): We do have problems in this area, see also my Goals section.