Difference between revisions of "User:Daniel/Council 2021"

Jump to navigation Jump to search
Line 22: Line 22:
I’m a believer of providing a stable base for anything people want to work on. To be accepted as experimental a XEP doesn’t have to be perfect. I’m also open to giving a number to XEPs that I personally don’t agree with or find otherwise controversial. I believe that there is room for exploring different solutions to the same problem. However I think that a XEP has to be implementable to be accepted. In the past Council has accepted XEPs that were just a bunch of ''TODOs'' or otherwise contained a lot of placeholders. I believe that an independent developer has to be able to look at a XEP and start implementing it.
I’m a believer of providing a stable base for anything people want to work on. To be accepted as experimental a XEP doesn’t have to be perfect. I’m also open to giving a number to XEPs that I personally don’t agree with or find otherwise controversial. I believe that there is room for exploring different solutions to the same problem. However I think that a XEP has to be implementable to be accepted. In the past Council has accepted XEPs that were just a bunch of ''TODOs'' or otherwise contained a lot of placeholders. I believe that an independent developer has to be able to look at a XEP and start implementing it.


=== Moving XEPs to Draft ===
=== Moving XEPs to Stable ===
There are currently a lof of XEPs stuck in experimental that are widely implemented and a working ''fine'' for a lot of people (Most noteworthy are Message Carbons, Message Archive Management, HTTP Upload).
There are currently a lof of XEPs stuck in experimental that are widely implemented and a working ''fine'' for a lot of people.


If we are going to consider ''experimental'' as a lower quality just-provide-a-stable-base kind of stage (see previous section) we need to move those XEPs that are widely implemented (and are obviously working for a lot of people) on to draft to make them distinguishable from XEPs that are not fit for use.
If we are going to consider ''experimental'' as a lower quality just-provide-a-stable-base kind of stage (see previous section) we need to move those XEPs that are widely implemented (and are obviously working for a lot of people) on to stable to make them distinguishable from XEPs that are not fit for use.


There is a chance that one or even all of the XEPs I used as examples above are not the most beautiful things the XMPP has ever come up with. But that doesn’t change the fact that these XEPs are different to the average lower quality experimental stage XEPs. The life cycle state of those XEP has to reflect that.
There is a chance that one or even all of the XEPs I used as examples above are not the most beautiful things the XMPP has ever come up with. But that doesn’t change the fact that these XEPs are different to the average lower quality experimental stage XEPs. The life cycle state of those XEP has to reflect that.


If we promote those widely used but arguably not 100% perfect XEPs to ''draft'' now and come up with a better solution later we can still ''obsolete'' them.
If we promote those widely used but arguably not 100% perfect XEPs to ''stable'' now and come up with a better solution later we can still ''obsolete'' them.


It is irritating that our Compliance Suits which are basically lists of XEPs to implement for a good & modern IM experience point to XEPs that then say »Please don’t implement me in production«.
It is irritating that our Compliance Suits which are basically lists of XEPs to implement for a good & modern IM experience point to XEPs that then say »Please don’t implement me in production«.
180

edits

Navigation menu