XSF Discussion - 2022-01-08

In general, everyone please remind the Newsletter is already open foe your contributions from whole December and January! Newsletter draft on Github: https://github.com/xsf/xmpp.org/milestone/3 (Navigate to the latest issue, then to 'Files changes', then 'Edit File') Or drop your news text to you online pad: https://yopad.eu/p/xmpp-newsletter-365days

the more i look at the standard process of XMPP the more i feel it runs into the wrong direction

The idea that the standard process is kind of open, with discussions and vote is honorable

but in my opinion it can only work if the people that vote on it, are really good kind of architects that have the whole picture in mind

probably they should contribute most of the standards themself or at least work on them

i bet at some point this was the case, now it feels like, everybody can send in XEPs, almost everything gets published as "Experimental" or whatever the current state is

I think we don't have that ideal situation because we do not have people who are willing to work on it

yes, i think there is missing a person or more that have this greater goal in mind and are ready to invest considerable energy into it

without that, we can make as much rules and governance xeps as we want

this will not help

Hence I am thinking that we should consider creating a space where everyone can publish ProtoXEPs under a stable URL, and only bring those XEPs to the council that we deem worthy (whatever that means) ✏

Someone with a Vision?

yes this can help, also what would proably help is something like a workgroup, a few capable people, that design an extension with some use cases in mind

I think such workgroups form itself when there are such capable people interested in a particular topic

flow, do you mean, https://xmpp.org/extensions/inbox/ ?

Link Mauve, maybe, but terminlogy matters and the process to

and how you present stuff

but ultimately, it would maybe already help to be able to put stuff in inbox/ without that being later presented to council

and given that recently a partly broken XEP was accepted in experimental, I wonder if our review processes are robust enough

You can ask editor not to run your ProtoXEP through the council while you send it to them.

Tricky when Authors have near infinite power to do whatever they want in Experimental, and Council is mostly a filter for advancement. Council can say "do this or we Reject!" or take over authorship. But Council doesn't magically have power to shape things unless council members are pretty active in discussions etc. Or something.

sure, I can ask for anything, but it's not part of the official process to have this option, no?

I think it is?

but its a hard problem to solve, probably a common problem in engineering, its even hard at the company where you dont put everything to vote and everybody can weigh in ✏

Zash, right. I think it's a problem of proper checks and balances within the involved parties of the ecosystem (probably mostly the XSF and XMPP developers)

lovetox, see also "design by committee" :)

institute a Benevolent Designer For Life ? 🙂

and a rich altruist that funds that party

i feel the worst thing that can happen to xmpp, even worse than not having a protocol for a special usecase, is to have 10 different for the same thing

yep, although multiple competitive protocols could be good in the long term. it is, again, about finding the right balance

but thats not engineering, i publish 10 things, and hope that one wins

That's why we need products, not (more) protocols ;)

For large parts of XMPP, it should be driven by client developers

At least requesting protocols if not writing them

The multiple competing protocols happen when the specs come before implementation

And when implementation comes before protocol, it's a different kind of fun

Of course

"Rough consensus and running code" all the way

*ahem* vcard-temp, siacs omemo