User:Larma/Council Candidacy 2019
Read about me on my user page.
Council Candidacy 2019
I don't consider the Council or any of its members an authority. The council uses its expertise to testify standard proposals using certain rules, but personal opinions are not part of it. If people say "X is not going to be accepted under the current council", there is something wrong with the current council or with the envisioned future council and both should be fixed.
To me, the two main tasks of a Council members are
- Testify if a XEP suffices the basic requirements for being accepted as experimental
- Testify if a XEP suffices the requirements for approval as Draft as defined in XEP-0001
While these tasks do require certain technical know-how, they don't ask for the council member's personal opinion. As a council member, I will try to stick to the process without including my personal opinion. If I am uncertain about specific issues in the XEP I will gather additional input from the authors, other community members and SIGs
That said, my criteria for accepting a XEP as experimental would be:
- It should be possible to implement the protocol described in the XEP with little additional guidance (ignoring ambiguity or issues alike). This is in line with the intention from XEP-0001 to encourage implementations of experimental XEPs.
- It should be able to move to Draft within 12 months, according to rules in XEP-0001, i.e. it shouldn't look like the XEP is going to be in Deferred status a year later.
- It should solve a problem. If it's not obvious which problem it solves, the problem must be outlined in the XEP itself. Personal opinions can be a valid problem description, as long as they are justified.
For the elevation to Draft status I understand "generally stable and appropriate for further field experience" from XEP-0001 such, that there should be at least two implementations of the latest version (not necessarily used a lot in the wild, but existing and tested for interoperability). I'd also like to ensure that we move things to Draft faster as well as to actually move things to Final if they become wildly implemented. As an example, XEP-0363 should probably be in Final already, but it didn't even reach Draft yet.
Moving things faster to Draft and Final status also means we should rarely do namespace bumps within a XEP anymore. That's because Experimental will become Experimental again (i.e. not widely implemented) and as such breaking things without a namespace bump in an Experimental XEP is actually fine. Draft standards however should remain backwards-compatible, which usually means that a namespace bump is not possible. If a significantly new iteration of a Draft or Final XEP is needed (that would imply a namespace bump), it should just start as a new ProtoXEP (and soon Experimental XEP).
I'd like to revive the concept of Special Interest Groups within the XSF. Among the reasons are:
- SIGs increase the collaboration within the members and contribute to a more common understanding of their problem space
- SIGs can produce XEPs as a team, reducing the work-load of each author while increasing the overall quality.
- SIGs can provide feedback on XEPs to the council, if they fall in their expertise. This is specifically mentioned as criteria in XEP-0001, but probably wasn't used a lot for quite some time
For a start I can imagine any of the following SIGs to be established
- Encryption SIG (OMEMO 2.0, full stanza encryption, "SeX")
- Mobile SIG (battery and data usage)
- Server/S2S SIG (MAM 2.0 etc)
- Jingle/P2P SIG
For the sake of completeness: Compliance suites are the only XEPs that are opinionated, as they don't follow any factual criteria, but represent the Councils opinion on what is to be implemented. However this doesn't affect protocol development itself.
Own XEP work
Should I be serving in the Council, I will obviously still continue authoring XEPs as needed. While I won't hand in proposals that I wouldn't accept myself otherwise, I pledge to always vote neutral on my own proposals to ensure neutrality.