180
edits
Difference between revisions of "Daniel Gultsch for Council 2017"
Jump to navigation
Jump to search
Daniel Gultsch for Council 2017 (view source)
Revision as of 10:43, 5 November 2017
, 10:43, 5 November 2017no edit summary
| Line 5: | Line 5: | ||
== XEPs == | == XEPs == | ||
I haven’t written a lot of XEPs myself but I helped clean up the wording or made other small improvements to other XEPs (see [https://github.com/xsf/xeps/commits?author=iNPUTmice my commit histroy on the XEP repo]) | I haven’t written a lot of XEPs myself but I helped clean up the wording or made other small improvements to other XEPs (see [https://github.com/xsf/xeps/commits?author=iNPUTmice my commit histroy on the XEP repo]). | ||
Looking into the future I'm currently most interested in XEPs that make (re)connections faster. [https://xmpp.org/extensions/inbox/isr-sasl2.html Instant Stream Resumption] is one of them. But we will also need to optimize the initial login/discovery process. | |||
== Voting == | |||
Since council doesn’t actually write XEPs the question on how I'm going to vote on other XEPs is more important than the question on what topics I'm personally interested in. | |||
On one hand I'm not afraid of getting rid of old things that are doing more harm than good (Remote Controlling Clients, XHTML-IM) or have been replaced by newer things (Message Archiving) on the other hand I try to avoid reinventing the wheel over and over again. Once we have a concept that is working and widely deployed I'd rather fix or improve that existing concept than to throw everything over board and start over. | |||
I appreciate XEPs that offer a very clean and simple solution for 90% of use cases rather than becoming very complex in an attempt to cover every niche use case out there. | |||
I'm driven by results and code. Show me that your XEP is deployed and working quit well for the majority of your users and I much rather vote for your XEP than having to read through hypothetical arguments. | |||