[Standards] Re: Council (and what it does, and what it should do)

On Mon, 2024-06-03 at 18:29 +0300, MSavoritias wrote: > Agreed. We don't need yet more XEP numbers to shift through. We > already > have way too many of them. > Instead we should start using the namespaces more. And also we > shouldnt > be afraid to update Stable XEPs if there are substaincial chan

[Standards] Re: Council (and what it does, and what it should do)

On Mon, 03 Jun 2024 16:06:37 +0200 Goffi wrote: > Le lundi 3 juin 2024, 14:58:23 UTC+2 Marvin W a écrit : > > > It's not as soon as your change causes incompatibility issues with > > other clients if they don't follow and also "move fast" and > > implement experimental functionality - and if eve

[Standards] Re: Council (and what it does, and what it should do)

Le lundi 3 juin 2024, 14:58:23 UTC+2 Marvin W a écrit : > It's not as soon as your change causes incompatibility issues with > other clients if they don't follow and also "move fast" and implement > experimental functionality - and if everyone needs to follow yours to > be compatible, it's effecti

[Standards] Re: Council (and what it does, and what it should do)

Hi, On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote: > Experimental is for the specification. Adding whatever status or > workflow change > you want will not prevent developers from implementing whatever they > feel is > relevant. People have been implementing things that were not official > XEPs

[Standards] Re: Council (and what it does, and what it should do)

Le lundi 3 juin 2024, 12:37:21 UTC+2 Marvin W a écrit : > The purpose of inbox is to ask for Council to review to move to > Experimental, it's not a location for developing a XEP. The location > for developing a XEP from its early stage is Experimental, however > Experimental is also where we have

[Standards] Re: Council (and what it does, and what it should do)

Hi, On Mon, 2024-06-03 at 11:02 +0200, Goffi wrote: > I completely agree with this. I don't think that creating another > status or > location for proto-proto-XEPs would be beneficial, as it would only > add more > confusion. We already have /inbox for this purpose. The purpose of inbox is to a

[Standards] UPDATED: XEP-0421 (Anonymous unique occupant identifiers for MUCs)

Version 0.2.0 of XEP-0421 (Anonymous unique occupant identifiers for MUCs) has been released. Abstract: This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users. Changelog: * Make exp

[Standards] Re: Council (and what it does, and what it should do)

Le dimanche 2 juin 2024, 22:43:27 UTC+2 Peter Saint-Andre a écrit : > 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 th

[Standards] Re: Council (and what it does, and what it should do)

On Sun, 2 Jun 2024 at 21:44, Peter Saint-Andre wrote: > 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

[Standards] Re: Council (and what it does, and what it should do)

Le dimanche 2 juin 2024, 21:33:55 UTC+2 Marvin W a écrit : > 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 easi