[Standards] Re: Council (and what it does, and what it should do)
On 6/2/24 12:30 PM, Florian Schmaus wrote: On 27/05/2024 15.07, Dave Cridland wrote: Equally, I've seen other proposals suggesting much higher bars for accepting a protoXEP, with in effect a pre-Experimental stage tacked on beforehand. I think this would be bad, too, and risks just accreting stages for no real benefit - but it's also essentially inevitable if the bar for accepting a protoXEP is raised too high. Such a pre-experimental stage already exists, whether we like it or not. People work on XMPP extensions, and if the bar is too high, they will just work on those extensions outside of the XSF [1]. And that is really a pity and something we should fix. What I'd like to see is that the XSF creates a place to cater for those ProtoXEPs (as how I will refer to pre-experimental XEPs in the following). Could be as simple as creating a directory protoxeps/ in xsf.git and ensuring that the contents of this directory rendered and available under xmpp.org/extensions/protoxeps. I hope that this will get us a long way towards fighting the fragmentation that we have [2]. Once again I would like to suggest that we make it easier to publish experimental XEPs (basically first come, first served à la Internet-Drafts at the IETF). This was our policy in the early days of the JSF/XSF, until the Council decided that it needed to exercise more control or, if you prefer, provide more wise oversight. XEP numbers are cheap and I don't see why we can't rapidly iterate and innovate within the XEP space (consider that XEP-0045 went through 30 versions over ~60 days in 2002 before being advanced to Draft). If that ship has sailed because we now have convinced ourselves that XEP numbers have deep significance, then by all means let's provide an XSF place for ProtoXEPs. But we should recognize that the same urge to control things will rear its head eventually, and then we'll have a discussion about an XSF place for ProtoProtoXEPs. It's "proto" all the way down! Peter ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Hi, On Sun, 2024-06-02 at 20:30 +0200, Florian Schmaus wrote: > Therefore, I suggest that the XSF embraces competition in the early > stages and, in case of duplicated efforts, limits itself to > advocating > certain extensions. I generally agree. However there has been cases, where a ProtoXEP is submitted without prior interaction was the community and then within the first feedback it is found that there is overlap in functionality with another XEP and that there is a good possibility to make them cooperate instead of compete. Often even the author agrees and is willing to do the adjustment, but changes to ProtoXEPs during the Council review phase are not encouraged (because they reset the voting). Competition might be purely accidental and we should filter those cases *before* they go Experimental (because Experimental is what people implement). I think we might want to have a "scribble" space, where people just dump ideas that certainly don't qualify as Experimental (e.g. because it's just examples). This should be super low barrier (and going through the git certainly is not) and allow for easy sharing of such ideas for very early feedback. In a perfect world, that would be an online tool where you can create and edit your own scribbles (using probably markdown) and make "edit suggestions" to those of others (that they can review and decide to merge or reject). Not sure if something like this exists, I am just daydreaming :) I think Experimental became a high bar not because of the Council, but because the processes don't match what people like to use during their early development and prototyping phase. However this is the phase where feedback is easiest incorporated. Marvin ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Thanks Dave, I really appreciate you kicking off this discussion. On 27/05/2024 15.07, Dave Cridland wrote: > I've rejected protoXEPs as arbitrarily as anyone else when in Council, > but loosely a few things crop up repeatedly: > * Unwarranted duplication of effort: The problem being solved is already > at least partially addressed by an existing solution, and it seems > better to fix that than wholesale replace it. I am very skeptical to have any kind of "duplication" criteria. First, in some cases there is no one-size-fits-all. Very possible that we we will not end up with the one-and-only XMPP IoT protocol extensions. But maybe multiple with different goals and tradeoffs. Secondly, the XSF should not encumber competition. At least not in early stages. And quite frankly, the XSF is also not in any position to do so. Just because a XEP is rejected, does not automatically mean that it will not get implemented. The developers and users of XMPP software also weight in and have an impact on the resulting ecosystem. Therefore, I suggest that the XSF embraces competition in the early stages and, in case of duplicated efforts, limits itself to advocating certain extensions. Equally, I've seen other proposals suggesting much higher bars for accepting a protoXEP, with in effect a pre-Experimental stage tacked on beforehand. I think this would be bad, too, and risks just accreting stages for no real benefit - but it's also essentially inevitable if the bar for accepting a protoXEP is raised too high. Such a pre-experimental stage already exists, whether we like it or not. People work on XMPP extensions, and if the bar is too high, they will just work on those extensions outside of the XSF [1]. And that is really a pity and something we should fix. What I'd like to see is that the XSF creates a place to cater for those ProtoXEPs (as how I will refer to pre-experimental XEPs in the following). Could be as simple as creating a directory protoxeps/ in xsf.git and ensuring that the contents of this directory rendered and available under xmpp.org/extensions/protoxeps. I hope that this will get us a long way towards fighting the fragmentation that we have [2]. We should make it crystal clear to readers of those ProtoXEPs that they did not undergo any expert review yet. As consequence, this means that the authors of those ProtoXEPs must be aware that it is not impossible that their specification may need a major overhaul before it can enter the 'experimental' stage [3]. In exchange, ProtoXEP may break their wire protocol without a namespace bump (which must also clearly documented). Consequently, this means that Council should focus on the technical side when presented with a ProtoXEP for adoption. With a particular focus on how idiomatic the XEP, when it comes to XMPP. For example, is there an attribute when it should be an element? And once a XEP has been honored with an number. Strict namespace versioning rules should apply. Interoperability is a valuable asset in XMPP land, that we must protect. Last but not least and not directly related to strict namespace versioning rules, but related to namespacing: I started to wonder if it were not better if we requiring a new XEP number in case of a namespace bump. This would help when referencing XEPs. For example, if I would task some random stranger to implement xep384, I would probably not end up with the implementation that I wanted. - Flow 1: This happened plenty of times, for example the various MUC alternatives (MUCLight, MucSub, etc.) 2. XMPP extensions residing on personal homepages and/or personal gits 3: A recent example for this was Guus' "PubSub Server Information" (xep485): At first reluctant, since there was already an implementation, Guus could be convinced that the wire protocol and XML design should be improved for the greater benefit. OpenPGP_signature.asc Description: OpenPGP digital signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] XEP proposal: bookmark pinning for user chats
"XEP-0469: Bookmark Pinning" specifies the implementation for bookmark pinning but only for group chats? Not sure if there is already an existing XEP for that, but one for pinning user chats would be useful. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
