Difference between revisions of "User:Jwi/Council 2018"

Jump to navigation Jump to search
1,014 bytes added ,  13:19, 3 November 2018
no edit summary
(Write words)
 
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
This is my (Jonas Schäfer) application for the XMPP Council for the term 2018/19. The election page is at [[Board and Council Elections 2018]].
== Contact info / meta ==
== Contact info / meta ==


I’m Jonas Schäfer, formely known as Jonas Wielicki. You can find me in XMPP related MUCs as '''jonas’''', or can [xmpp:jonas@wielicki.name contact me via XMPP] or [mailto:jonas@wielicki.name email]. More contact info and meta can be found on [[User:Jwi|my user page]].
I’m Jonas Schäfer, formely known as Jonas Wielicki. You can find me in XMPP related MUCs as '''jonas’''' (formely jonasw), or can [xmpp:jonas@wielicki.name contact me via XMPP] or [mailto:jonas@wielicki.name email]. More contact info and meta can be found on [[User:Jwi|my user page]].
 
I am currently employed as DevOps Engineer at CLOUD&HEAT Technologies GmbH.


This is my first application to the Council.
This is my first application to the Council.
Line 17: Line 21:


* Make our specifications more useful to new and existing developers. This means in particular:
* Make our specifications more useful to new and existing developers. This means in particular:
** Ensure that identified edge-cases well-defined in the specifications
** 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, [https://xmpp.org/extensions/xep-0045.html XEP-0045]).
** 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, [https://xmpp.org/extensions/xep-0045.html XEP-0045]).


Line 24: Line 28:
** Work on multi-device use-cases: Drive and support the development of IM Routing NG ([https://xmpp.org/extensions/xep-0409.html XEP-0409]), as well as improvements regarding configuration sharing between clients and with the server (think notification preferences).
** Work on multi-device use-cases: Drive and support the development of IM Routing NG ([https://xmpp.org/extensions/xep-0409.html 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 [https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ 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.
** 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 [https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ 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 ==
.. as I see it. (This section is inspired by the similar section in Kevin Smith’ application)
* Attend the meetings as reliably as possible.
* Judge contributions to XEPs where Council has to decide about the acceptance for the bettering of the protocol
* 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)
* Comment on the standards process
* 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)
88

edits

Navigation menu