88
edits
Difference between revisions of "User:Jwi/Council 2018"
Jump to navigation
Jump to search
extend
m (fix typo) |
(extend) |
||
| Line 26: | Line 26: | ||
** 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) | |||