User:Jwi/Council 2019

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

Contact info / meta

I’m Jonas Schäfer. You can find me in XMPP related MUCs as jonas’ (formely jonasw), 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 second application to the Council. You can look at my previous application.

Who am I / What are my qualifications?

• I have served as an Editor in the XSF for two 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 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

• 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)

.. as I see it. (This section is inspired by the similar section in Kevin Smith’ application)

• Attend the meetings as reliably as possible: This has worked quite well in the past year.
• Judge contributions to XEPs where Council has to decide about the acceptance for the bettering of the protocol: This has worked fine for me for the most part, but there is a huge block of XEPs I did not feel comfortable judging: All those related to Jingle. Others had similar issues. I for myself came to the conclusion that for this type of specification -- where it is not feasible or rational to dive into the entire tech stack within two weeks for voting -- it may be reasonable to mostly rely on the word of those familiar with the Jingle stack. I realize that this is not perfect, but I think that's the closest I can manage while doing this in my free time.
• 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): That has worked mostly fine I think.
• Comment on the standards process: 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): I tried this, and it has worked only to some extent. I think we need a better on-boarding process for new authors, but I'm not sure how much of this is the role of council.