XSF Discussion - 2017-09-26

I think the reason good ux goes against security is because those are generally different developers

Especially for web

moparisthebest: i just remember how Constanze Kurz from CCC said something like: 'we need to bring students from other disciplines in contact with IT - even so art students'

FLOSS needs more designers indeed

👍

and as a tech student say so too. why am i 'locked' into a pure technological based university? so we need the other way round too

yup I agree

art can be learnt actually (especially graphics design, where you basically only need to pick right colors and shapes), but nobody wants to do this

I doubt that "nobody" wants to do this, there are quite a few graphic designers out there.

jonasw: ok, I mean a typical developer

I just think it’s pointless to force yourself to do something you don’t like if you could be doing something you *do* like (and possibly even are already good at).

better get an interested graphics designer involved

how?

how will s/he join xmpp?

via photoshop?

zinid, they don’t need to join XMPP to contribute.

(whatever joining XMPP means)

can you please describe the working flow of such designer?

I have no idea of designer workflows?

I have :) I hired some back in the time

then you can shed some light on it :)

what I meant is that there should be incentive for a designer: money or interest

since s/he's not joined XMPP (not interested) only money left

Everyone have their motivation sources

zinid, I don’t think that "isn’t part of XMPP" (still, whatever that means) implies "not interested" for sure

in 15+ years of xmpp development I can barely remember as single designer

it can also imply "doesn’t know the key point which leads to interest yet" or "doesn’t know about XMPP at all yet" ✏

#Opensourcedesign on Freenet

*a

zinid, that’s maybe because most of XMPP development takes place in the FLOSS community, where there are generally only few designers abound

(and what doesn’t take place in FLOSS often doesn’t announce XMPP that loudly)

Freenode**

Have there been any studies on the general lack of designers in FLOSS?

Zash, either there is a general lack, or they are mostly horrible ;-)

90% of everything is horrible

jonasw, zinid: I think in first hand it is important for devs and designers to get an understand of each focuses and how they think. thus the designer and devs can adapt their work or workflows to bring them together. that why I said combine the studies or at least let them get in contact. i think both sides are interested in each other. but there is no need for each side to do others work if they dont want to. so just get an understanding. what makes good UX, what makes good security? (e.g less is probably more!) and so on. there are lots of (mainly) non tech people in the CCC for example

+1 emxp

eh

So we need to acquire some designers...

actually, whats the puropose of XSF? Do you collect money, too? For example, to pay people for specific programming/design tasks?

I would say XSF cares about XMPP, the protocol.

Software is a thing for developers.

probably collecting money and hire designers is not that bad idea

SouL: maybe there should be an extended foundation or so. in principle like Google Summer of Code. but only for xmpp purposes

i would donate money

This foundation furthermore could spend money on other things which supports xmpp too

emxp: I think XSF has donations already

exmp: The XMPP Standards Foundation (also known as the XSF and formerly the Jabber Software Foundation) is an independent, nonprofit standards development organisation whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP).

copy/pasted that :)

as for sponsorship - that's obviously very welcome. There's a sponsorship programme defined here: https://xmpp.org/community/sponsorship.html On top of that, we occasionally ask for sponsorship regarding individual events (mostly the XSF Summits)

I think what we really need is more full-time developers, 95% of xmpp projects are maintained in spare time, most of the projects can barely survive 10-year period (I can count only a few)

arguably a very good way to support the XSF, besides donating money, is to be actively involved in the activities that we undertake. There's a lot of things that we do, from defining protocols, to providing internal support (to our website, this chat, preparing for conferences, etc)

Guus: donating to XSF will not help xmpp in my opinion

zinid: I don't think that's something that should be initiated by the XSF. The XSF is there to develop the protocol, not the implementations.

Guus: I don't say XSF should do that

Well, there are plenty of open source, but also commercial organisations, that do development on XMPP

I'm sure that many of these will gladly accept help

By the way: most of the servers listed on our website are older than 10 years. There definately is a solid foundation there.

Prosody is 9

I almost always talk about clients when I say "xmpp software" :)

Client software is harder - platforms and UIs change

no surprise we have some servers with commercial support, because it's easier to build bussiness model with them

All the 10-year clients around, people now call them ugly

MattJ: exactly

zinid: so, open up an IDE and start typing :)

Wrong shade of grey

there's a good deal of libraries available that you can (re)use to create new stuff

but you're absolutely right - we could really use more nice clients.

Guus: I cannot do everything myself, obviously, I'm a server dev

I think that the XSF urgently needs to widen its scope from "protocol" to "software", so it can provide UX guidelines etc.

back to*

yaxim is only eight years old :( ✏

I'm not sure if I agree, Ge0rG.

Recreate the Jabber Software Foundation as a separate entity

Zash: I've been pondering about that.

On first thought, I'd prefer that. Will have to give it more thought though.

Zash: but the main issue I see is: it will be run by a subset of the same people as the XSF, and those are already short on time.

Guus, zinid, Ge0rG: Yes, its good that XSF is focusing on the protocol. so my suggestion was to focus with another on implementations and full time payments

for devs

or part-time in the beginning

Where'd the money come from?

Besides, I'm convinced that "protocol" also includes defining certain user-facing elements. Like how to call entity addresses for that protocol.

emxp: again, I'm not arguing that it's a bad idea. I don't think you'd need a separate organization for that though, as existing ones will be very happy to accept your help.

emxp: there is an initiative to collect money for Jingle support in conversations, it ended up with 500$ or so ;)

emxp: you need a dozen developers and a year of time to make a well-polished XMPP client. So if you have a million dollars, let me know.

nobody wants to donate

Sure there are people who want to donate, but you aren't going to get full time developer pay from donations

take a look at Matrix, they have funding problems and started fundrasing, the result is 2800$ : https://www.patreon.com/matrixdotorg

and Matrix is quite hyped at the moment

zinid: arguably, they _now_ have funding problems, because they started off as a fully funded project (which suddenly lost its sole sponsor).

and Matrix has 11 developers, lol :)

-do 2800 / 11

Zash: 254.54545454545

what a bunch of money!

zinid, what do you propose?

for their london office this pays for the oyster card they need to get to work

Guus: I would propose something if I knew, I see no solution

Somehow attract people willing to spend their free time on making things better.

or somehow attract their money

Charge users $1/year for using your app

MattJ: that didn't work, whatsapp was still unprofitable before the acquirement :D

Sell your soul to Facegoogle.

And your users data.

I have neither soul nor users data :(

Raise money for a marketing campain in order to raise money for writing a client.

Marketing marketing marketing!!

Uh, what do you want to do with me?

Sell you, obviously.

SouL, sell you

One SouL, in mint condition, do I hear any bids?

Nooo

09:45:39 zinid> I think what we really need is more full-time developers, 95% of xmpp projects are maintained in spare time, most of the projects can barely survive 10-year period → I lightly updated the jabberfr wiki yesterday, it is full of clients dead in the last 10 years

Projects dying isn't necessarily a bad thing tho. Something something Darwinism.

yeah

but it’s bad because I’m the only one who updated the wiki after 2011

so, "popular mobile clients" had J2ME and "popular clients" had coccinella

If we can't manage to update a wiki, I fear for development projects...

Guus, that’s mostly because we had a very motivated guy doing it before then

Which, coincidentally, why I've started to help out with maintaining the stuff that we do have, as XSF.

mathieui: perhaps removing outdated data is better than keeping it unmaintained. Nothing puts people off as much as seeing information that's clearly incorrect.

I'm positive that things like that have a negative impact on people that consider contributing. I'm afraid we're loosing people, before they even started.

Are the json files used for client list generation hosted on xmpp.org as well?

We are losing people everywhere!

Ge0rG: referring to the software listing? Yes, used for all software

Guus: not "used" but "hosted". The actual JSON files. So that external services could use them.

Ge0rG: that's my fear. The good news is that improving our data can be done by anyone. It's an easy PR away.

Ge0rG, that’s why I started that

that and adding conversations, chatsecure, xabber

Guus*

Ge0rG: Ah, unsure. Well, you could always refer to the stuff in Github, but I don't think it was intended that way.

mathieui: thanks :)

Did we update the Prosody file?

"the Prosody file" ?

Prosody is listed on https://xmpp.org/software/servers.html, if that's what you mena.

zinid: i siggest first lets ask, how many money can we collect. and how can we spend it. what needs to happen to increase donations

emxp: where/whom to ask?

Oh, https://github.com/xsf/xmpp.org/commit/600d7f4d484c69ef3d631f40b7d65d9258015291

If XSF is okay to do task expanding the Protocol thats nice. but so far I didnt saw that they are not interestet

zinid: ask generally

emxp: the XSF doesn't seem interested to do things beyond protocol development. And that's hard already.

> Do one thing, do it well.

And separation of concern.

especially because we're already having a hard time with that, I don't think the XSF should be taking on more.

Well, that would imply that XSF favours specific clients and such, if I understand correctly.

SouL: not at all.

There is plenty of possible improvement between "the XMPP protocol" and "Make Jabber Great Again"

Ge0rG, emxp would like to collect money for devs, or not?

SouL: right, collecting money for developers would be rather hard.

But, again, if anyone wants to support clients: give the existing organizations your support. You really don't need the XSF for that.

Either the XSF would create "the reference client" from that money, competing with XSF members, or it would have to devise a biased way to give money out.

Guus: the existing client developers?

XSF + reference client -> bad idea

Anyone + reference client -> bad idea, I think.

Not just the XSF.

Ge0rG: https://xmpp.org/software/clients.html

How long have people said "the xsf should do a reference test suite"? :)

reference server is a good idea! I have one to suggest :D

Me too

2 reference servers is even better

Guus: I know that page. My question was, whether you imply "client devs" by "existing orgs"

Zash: a reference test suite would actually be something where I can see the XSF paying for development.

Except that Daniel now almost implemented one.

Orly?

Ge0rG: I'm desperately trying to avoid naming names (as I'm personally involved in one of them) - but various clients have OSS organisations behind them that would gladly accept support.

what will the suite test?

servers?

because I don't know how to test clients

do we have shitty servers? no, we have shitty clients

Guus: I'm not asking for names, but for clarification of your statement :)

zinid: that's a blatant lie! We have shitty servers AND shitty clients.

no way

zinid: you don't happen to be Evgeny from the ML?

https://en.wikipedia.org/wiki/Sturgeon%27s_law

Ge0rG: find the organization of the client that you want to see improved, then support them (either by joining as a dev, a community member, or by donating resources)

Ge0rG: that's me yes

Guus, SouL, Ge0rG: Yes, XSF shouldnt do an additional task. a new foundations may collect more money, because it is maybe more obvious where the money goes. if you can see projects

directly

zinid: nice to meet you, and welcome to the XSF MUCs, where all the "inactive" members hang around :D

:)

Ge0rG: It's not just the developer that needs supporting, it's the entire organization (formal or informal) around the development effort. Some of our most valuable members write no code at all.

(That's where my distinction between Dev and Org originates)

Guus: that's probably true. Still, sponsoring individual devs/dev-orgs is out of scope for the XSF, and rightly so.

ge0rG: I agree completely. I've been stressing that the XSF does not need to be involved, but instead, people could reach out to those dev-orgs directly.

yes, XSF should not collect donations

it's pointless, they need to share them somehow between projects, that's hard

Guus: except there are no people who want to contribute significant amounts of money.

Sure it should. But not to sponsor one particular implementation.

Guus: and how to share between the projects? on what basis? equally?

Ge0rG: All I'm saying is that the XSF need not be involved if someone wants to do sponsoring of individual projects :)

zinid: you do not share at all. You use it for the activities that the XSF does itself.

Guus: yes. But the more important question is: how can the XSF contribute to a future where we do have non-shitty clients and servers?

Guus: ah, ok

zinid: the XSF can still pay for Summit Dinners and XMPP stickers.

I wish we had Jabber stickers.

Ge0rG: facilitate development by having an up-to-date library of information (the XEPs, the Wiki, the webpage) and provide avenues for discussion (like this MUC - that still could use a web frontend - the mailinglists, and perhaps others).

a web frontend for this MUC would require developing a web client.

regarding jabber tickers, isn't this XSF responsibility?

*stickers

Ge0rG: it further can host or be present at gatherings (like FOSDEM) and spread the love. Have meetings with stakeholders (even informal ones, like the Summit Dinner).

how to post stickers?

yes, the SCAM workgroup has stickers and leaflets and stuff, to be used in XSF activies like I described above.

Guus: the XSF is doing that for 15 years, and we still have shitty clients and servers ;)

SCAM will (and has) happily send those out to people that are hosting such events.

Ge0rG: There is much that the XSF can (and is in process of) improve: the XEPs were completely outdating up until recently, the Obsevatory is still gone, the wiki and webpage have shown outdated information for a very long time, etc etc.

Ge0rG: getting that in order won't magically fix things, but it will surely facilitate - and it is stuff that we can do _now_, without needing to discuss what other activities we might want to spin up.

We're already stretched - adding more work won't improve things.

Guus: indeed, you are right.

as a side-note: perhaps we should rename the 'experimental' status of a XEP. One of the recurring criticisms that I read is "Pretty-standard-feature XYZ has a XEP that is only "experimental"!

Yes, that's true.

it's just window dressing, but sometimes, that makes a difference.

"draft" isn't much better either.

Some XEPs live their whole life in "draft"

Guus, what we need to do is either make the XEP status reflect real world perception, or add another status that does

Ge0rG, did I mention that 0059 is still draft?

mathieui: I agree.

0045 is fifteen years now, and still in Draft.

There are probably XEP-0045 implementing developers younger than that.

That's why I think we should find a better name for Draft before thinking about what to do with experimental

"Work in progress", "Almost done", "Done" ? :)

"Broken", "Stale" and "Rusty".

Zash: Doesn't actually sound that bad

Zash: replace the last one with "Carved in Stone"

FINAL wait that's what it's called

Skip that, jump to "Obsolete"

Hah

"Living document" -> "Dead document"

+1

Welcome to the internet

"Request For Comments"

what I personally would like to see is how many implementations support the XEP, and probably range the XEPs in this order

this is only what makes sense, because even Final can be implemented nowhere

zinid: Define support. Which leads back to the whole test suite thing.

Zash: claiming support is ok, even partial

Pretty sure Final requires two implementation.

s

Zash: also goat blood sacrifices

Or was it Draft?

I forget

https://xmpp.org/extensions/xep-0009.html

this is final

where is it implemented?

Version 2.0 (2002-12-09) Per a vote of the Jabber Council, changed status to Final. (psa)

Could 'Subject to changes' be used for 'experimental', for example?

Or we should use just a word?

SouL: I think every XEP should be "subject to changes", we have namespace bumps

the only difference is probability

so "in development" and "more or less stable" is enough

dunno why there so many gradations

Experimental = "In active development"

still says nothing for me, I need to see where it's implemented

When it stops being in *active* development it goes into deferred

Similar to how IETF drafts expire after some months.

Should the XSF try to keep track of implementation status?

why not?

I don't think this is a lot of work

only creating some form

where everyone can submit

Periodic calls for experience?

no matter, something that would work without tons of pain

What about a "compliance badge" that can be assigned after completing the compliance suite.

Maybe when things go deferred, send out a survey thing asking if anyone has been working on an implementation?

This client fulfills [Jabber Gold Premium]

I've just posted on standards@ about the XEP status name change. I'm interested to see what others think of this

with that, I'm disappearing into the world of managers, deadlines and stale coffee.

Don't do it!

Zash: "send out a survey" <-- where to send it?

Mandatory JIDs everywhere!

The standards list

I think not so many people are in active conversation with XSF (list, chatroom, etc)

I almost never see Gajim devs in the list

maybe they are here?

Actually, I think the core of the proposal is to send out a call for experience along with the deferred message.

nah, I was suggesting to track the number of implementation right in front of XEP title or so

Sounds like a task for a web service.

Figuring out if a XEP became inactive because everyone already implemented it or because nobody implemented it would probably be good.

Zash: isn't that what "Final" vs. "Obsolete" is for?

Ge0rG: It's "Which direction should this Experimental XEP go?"

didn't follow the whole discussion, but about deferred, we may have nothing to add to a XEP, but waiting for implementation or something else before asking for move to draft. It would be nice to be able to do an update without modification, just to show it's not abandonned at all.

Ge0rG: a really simple submitting form is enough, which will put numbers in the database for displaying, I don't think this is brutally hard

There exists survey tools, if someone wants to automate it that way.

zinid: web forms will be immediately overrun by spammers.

well, using existing tools is preferable of course

sigh

how others do this, cannot imagine

for the record, tracking progress for OMEMO is one github repository: https://omemo.top/

Could be as simple as adding "Have you implemented this? Send comments plz." on https://github.com/xsf/xsf-tools/blob/7628fe8610e3d7f2247e5e7634bbf6c754c2d033/xeputils/mail.py#L114-L125

zinid, gajim devs are not in there, no

that's pitty because this is one of the most popular desktop client (although not everyone like it)

and we don't hear their opinion

so, get them in here :)

mathieui: Asterix is writing from time to time on @standard

we cannot force every developer joining this room or the list

Make them an offer they cannot refuse ;)

the issue with gajim devs is that they really are busy (it’s mostly lovetox these days, with asterix showing up from time to time)

what I want to say is that we shouldn't expect lots of responses from developers and drawing conclusions based on received responses

zinid: do you have a better proposal?

Ge0rG: tracking existing implementations is a good start in making some decision (such as deferring for example)

maybe we could first track what XEPs are implemented in which clients

zinid: but how?

it's not that hard https://nl.movim.eu/?about#caps_widget_tab

Ge0rG: are we going circles? :) submitting form?

the point is everyone can submit

so even if developers are busy their users can submit

another advantage is of course everyone can decide about XEP popularity by implementations number

instead of experimental/draft/etc nonsense

Everyone implementing something doesn't make it good.

Good things don't usually win popularity contests in my experience.

really? in the context of standards?

which means the standard is crap? :)

do you remember such situation in xmpp?

edhelas, caps widget is not enough

Good enough combined with timeing on the other hand.

Or marketing.

the issue is, more than asking dev to be aware of new XEPs, is also to push them to deprecate or remove old ones

mam:tmp, vcard_temp, Private XML…

vcard-temp and private xml are good enough, but not really that good

Multiple versions of the same XEP is a somewhat different issue.

back

goffi, if a XEP doesn’t have implementations, moving it to Deferred is a sane thing. There must be something wrong with it: either it has issues deterring implementors or it is not needed at all. Void updates are not going to make any of this go away.

zinid, if users submit on behalf of their software, we’ll be getting incomplete and inaccurate data, that’s worse than no data.

(e.g. "does this client support Jingle File Transfer?" "well yes of course, I can send files", but in fact the file transfer is using HTTP Upload)

jonasw: why would we have inaccurate data?

I don't say it would be 100% accurate

zinid: because users are clueless.

what Ge0rG says

zinid: it would be 40% accurate and there would be multiple submissions.

Ge0rG: a clueless user who knows what xsf and xep is?

https://www.zash.se/xmpp-clients.html inaccurate!

zinid, sure

User often already fail at spelling a client name correctly.

If clients put XEPs into their marketing, then users will be somewhat aware of them.

Guus, regarding donating money to client organizations: there are enough clients out there which do not have an umbrella organization

then what makes you think a developer is responding on your last calls?

some of which are doing great work in the UX department (I heard dino is nice)

accepting donations is tricky

I'm working on a system for people with technical background, and they fail to properly spell their own name.

maybe that's a clueless user responding

zinid, you got me thinking that we sohlud probably issue CFE and LC to the developers list too

jonasw: you need to find developers there first :)

zinid: I think you just volunteered to create a web form, collect data from users, developers or goats, and to process it in a way that's suitable and useful to the XSF, thanks!

khekhe

Ge0rG: sure, and you go develop ejabberd

fair trade

tough choice

erlang vs. web development

jonasw: deferred != no implementation. I'm author of XEP-0355 and XEP-0356, they have 2 implementations (at least), and just didn't need to update them

zinid: sorry, I've got my own client to develop, and I'm submitting issues for a bunch of others.

and they are deferred

anyway I now need to update them so it's not a big deal.

goffi, if there are two implementations, you should ask for advancement to Draft.

jonasw: now, because I need more tests

too early for that

zinid: but while you are here, you can solve my ejabber MUC bug: all MSN clients are kicked when one of the MSN clients sends an error to the MUC.

s/now/no/

jonasw: clients without organiations typically have one developer. Donating then often is done in the form of temporary commisions ("can I hire you to build this-and-this in the client"). Nothing dangerous about that.

Guus, it is massively tricky if you are employed elsewhere

I am kind-of glad that we didn’t get into the Prototype Fund, because I didn’t want the headache of coordinating with my employer and insurance etc.

(maybe that’s only a german thing that these things are complicated)

Ge0rG: I cannot drop my tasks and fix your issue, create a github issue maybe? if there is a bug it will be fixed quite fast

zinid: I'm not the server operator, so I don't have logs.

jonas: true, that can be tricky. For me personally, it's not been a problem, as when I was employed, I've always made sure to have a clause in my contract that allowed for it. Now that I'm self-employed, things are even easier. But yes, it does require some planning.

Guus, I don’t even know how such a clause would need to look like, really.

perhaps we could facilitate that planning in some way, shape, or form - simply by letting people interested get in contact with people with experience.

Ge0rG: I can only say I will check if I don't forget (like always)

zinid: also you seem to have enough time to make proposals here and on standards@ .P

Ge0rG: nice try :)

zinid: you know, I've once waited multiple years on an ejabberd ticket. Then I gave up and switched to prosody.

jonasw: from exprience, every employment contract that I signed (which have been 4) had a non-compete. When discussing the contract, I'd mention: "but i do work on ... which I'd like to continue doing" after which we had some back-and-forth, and a clause was added.

I might've been lucky, unsure, but it always worked out.

Ge0rG: and now waiting years on prosody tickets, ok

(and it has the added bonus of having HR work out the details of the clause :P )

Guus, right, will take that into account when I get my employment contract soon-ish

Guus, my employment contract has a "all your personal work belong to us, even outside of work time", and I ignore it because it’s illegal, but meh

mathieui, wtf

I thought they would do that only in the USA

zinid: EJAB-532 took four years for a community workaround. I've got two more years to go with prosody before reaching that timeout.

mathieui: I don't recommend knowingly accept a contract and disobey it, even if it's an invalid contract.

Guus: sometimes that's better than not having an income.

i've always had my feedback on a contract draft addressed by HR - but again, that might be lucky.

Ge0rG: so what is your conclusion? every ticket takes years to resolve? this is not true of course, you can check dynamics on github

Ge0rG: I was assuming that it wasn't even discussed before signing it.

Ge0rG: if it *was* discussed (but still disallowed), then I'd more so advice against breaking it!

Guus: I've had a talk to my now-boss regarding illegal parts of the contract, and he said "we've got that in all contracts, we won't make an exception", so I shrugged it off.

Ge0rG: I might have been lucky with my employers then. Might be a cultural thingy difference between the types of organisations we work for.

And this is what happens if you don't have unions

daniel, does conversations.im already have a union? :)

the boss wouldn't allow it! ;)

daniel: don't go Set Theory on us!

What?

unions, intersections, etc.

now we’re at traffic managment!

who can give SCAM-wg access to the XSF twitter account?

mathieui: for my last job in France, I've made the company bosses sign a paper saying they knew that I was working on my project on my free time, and wouldn't claim any right on it.

mathieui: anyway, I don't think they have any right on what you're doing on your freetime, whatever the contract is saying (but I'm not a lawyer of course)

Zash> If clients put XEPs into their marketing, then users will be somewhat aware of them. < I'm thinking more and more users shouldn't be aware of the impl. details (i.e., XMPP). But maybe it was sarcastic and I didn't catch it

pep.: true

well depends to who you're doing "marketing"

when I'm doing release notes I can go into lots of XMPP details but I prefer most of the time to stay with "upload files feature" with a reference to the XEP than explaining the whole stack

edhelas, sure

Go to various clients web pages, search for XEP, count matches.

I'm not talking about devs, nor poezio (console client) users

I think there was recently a proposal for a formal client description language, including XEPs.

indeed

that’d also work for gathering implementation stats by the way

jonasw are you talking about https://github.com/movim/moxl#xmpp-support or https://github.com/dino/dino/wiki/Supported-XEPs ?

neither I think

let me get you a link

edhelas, https://mail.jabber.org/pipermail/standards/2017-August/033123.html

okay :)

goffi, care to reply to daves email on standards@ with your example?

I think it’s relevant to the discussion

jonasw: sure

goffi, '355/356? If they "don't need updating", then they're surely ready for advancement?

dwd, "I now need to update them"

dwd: I have now updates to put. The thing it take time to have implementation, and it take time to implementation to mature. For instance in the case of 355 I've realized that disco items were not handled correctly in my Pubsub service, and this need a slight change in the XEP. I'm using this Pubsub service with XEP-0355 for more than one year, but I've just realized this was missing a couple of weeks ago, and I wanted to test implementation before modifying the XEP.

Either the XEP *is* expected to change in an unstable manner, or else it's ready for advancement. If it's expected to change in an unstable manner but isn't being actively edited, then it gets deferred after a year. Which part of this are you objecting to?

dwd: I'm not objecting to anything, I just say that the XEPs are deferred but not abandonned, just on hold. I'm writing an email on standard@ to explain that.

> I don't think this is a lot of work Yes it is. No matter what the thing is, if someone says those words they're wrong or they would have done it already.

SamWhited, I don't even know what you['re quoting, and I agree.

dwd: Yah, those words were said earlier (about something that I suspect editors would end up having to do).

It made me cringe. I still think our process is too complicated and that we've already forgotten about it again because we have new editors that are rosie eyed and not burnt out yet so work is getting done and we'll ignore the problem until they get burnt out and we get new editors again.

But it applies in general too.

SamWhited, I think our process has acrued a lot of cruft and assumptions and special cases that it shouldn't have (and isn't even documented to have).

dwd: Indeed, it needs some love.

SamWhited, I think understanding what it was meant to be would be useful. The fact people think we need a stage before Experimental suggests to me that it's very poorly understood.

dwd: I agree

dwd, the question is whether that lack of understanding comes from lack of documentation, lack of active education or something else

in any case, if newcomers or people taking only a quick look don’t understand it, it’s a PR problem we should fix. and that often has to do with naming

jonasw, I don't think it's well documented, and I don't think people read that document very closely. In addition, this problem has become acute because we've lost a chunk of our institutional knowledge - lots of long-term (ie, decades not months) community people have drifted away over the past year or two.

jonasw, There's other problems with our process too, like no (real) IPR policy, and no appeals process. Both block us from being "Open Standards" in the openstand.org sense.

Actually, I agree and disagree. I agree that "draft" is poorly misunderstood and think that we should rename it (it doesn't "sound like" the name implies "you should implement this, it's done"). I think experimental is fine and people probably do understand it (it's experimental and you should only implement it if you're comfortable implementing things that might change). The problem with experimental isn't one of naming, it's that we leave things in experimental too long.

"it's experimental and you should only implement it if you're comfortable implementing things that might change" The same is true of Draft - they *might* change, we just try not to.

(Actually, that's not true, we try not to in ways that are backward incompatible)

SamWhited, I agree with you. But that doesn't explain people who want us to have a stage before Experimental, or who want XEPs to meet certain quality gates before Experimental, and so on.

s/that might/that are likely to/

dwd: Ah yah, fair. I do think that's misguided. I do think a basic quality gate is fine though, it should at least be possible for me to implement it before it goes to experimental.

Kev, We generally don't change Experimental in ways that aren't backwards compatible - we're just (more) open to abandoning the namespace and minting a new one with namespace versioning.

I think 'Not obviously stupid and not duplicating existing stuff with no clear differentiator' is the check I used to do for +1ing Experimental.

dwd: Changing the required namespace is about as backwards incompatible as you can get.

When talking about compatibility of the document, not of a particular namespace within it.

Kev, Well, sorta. The old namespace still works, nothing is broken. But yes, it's a clean break rather than maintaining interop.

Added a card for board to discuss the rename.

And one on council to make a recommendation.

renaming draft to stable and striving to not keep things in 'experimental' for to long would be big wins, I think.

I agree

if, on top of that, we can apply structural simplifications to the entire process, even better. Suggestions?

I’m currently fine with the XEP editing process, mostly because I automated the parts which can be automated (and which I had contact with, there’s some stuff I haven’t done yet, like Last Call)

jonasw: but you fall in Sams 'new-and-not-yet-burned-out' category :)

maybe

the level of automation helps against burning out though

needs moar autmoation though

Always moar automation

I need to figure out how to make a github bot which can post metadata of all touched XEPs in a PR

absolutely, but automation needs maintenance too.

it is annoying to have to look up the status and authors of a XEP manually inside a diff

I'm heading out again, but I'd be very interested in hearing practical improvements that we can make to the process.

something which detects when a namespace bump must happen would be amazing

but I doubt that’s possible

(maybe something which warns when RFC 2119 words are touched)

Which doesn't imply that it needs a namespace bump.

I know

but it’s still something good to see quickly when processing a PR

I’m bad at reading diffs

jonasw: Any diffs or XEP XML diffs in particular?

Zash, XEP diffs are especially bad because of long lines

I can read diffs fine. I can barely read XEP XML when it's not a diff.

or alternatively, because of line-broken text

Anyone wanna continue my work on turning xeps into text/markdown for simpler diffs?

Zash, dump the code somewhere, I may take a look

doesn’t help much when viewing diffs on the repository online though

Jokes aside, as much as I like the idea I don't think we need more tooling, more things to maintain, more stuff to break, or more things you have to know about and learn to use.

Which is a long way of saying what jonasw just said

I’m not sure how I said that

> doesn’t help much when viewing diffs on the repository online though

ah

well, actually, in the back of my head I mentally added it to the list to integrate in a possible github app for which I have an idea

I need to take a look at the effort involved. Something which is geared towards XEP PRs and can do a great deal of the initial triaging process automatically and/or simplify the triaging by putting all relevant information in once place would be amazing.

jonasw: https://gist.github.com/Zash/372591d4c61b6af70d810a78bd1af12d

Zash, can you dump a quick list of todos below that?

jonasw: I think the main blocker for me is that I don't know how to proceed, or what to do with it.

from what I can tell it converts xep-xml to markdown, right?

The Lua thing does that, yes. One shell script to normalize its input and one that picks two versions of a file out of git and compares them with the previous scripts.

SamWhited, so what _does_ help?

Guus: What does what help?

You earlier referred to a benefit of making 'the process' less complex. I agree with pretty much everything that you wrote, but I'm still not sure what a pragmatic improvement would be.

Guus: I wrote a long email about this actually, I will forward it to you if I can find it. There's also a trello where I put a few of the potential improvements

Some of them have been done, it's definitely a bit nicer now

if there are sensible improvements left, by all means, lets implement them.

let's put things on the radar of those that are to decide on things.

The only two things left that I think we could reasonably do are automating email (sounds like jonasw is working on that a bit, we'd just have to integrate it with the build) and automating archival of XEPs as part of the build (I still have no idea if we have an attic or how it works in the new docker land, so if that still needs to be fixed it might end up being a lot more work)

ah, okay, that's automation. I though you were referring to procedural changes (eg: make XEP-0001 less complex, or something in that nature).

Oh I see, sorry

A thing that I've wondered about is, is there a good way to map* XEP versions to commits? ✏

not to say that the automation bit wouldn't be wildly helpful.

Zash: not really; I was going to suggest some git foo, but apparently some XEPs have multiple revisions with the same version or where a version ended up going backwards somehow.

So maybe we need to improve CI as well

SamWhited: maybe it's worth manually revamping those XEPs, for the greater good?

Guus: Yah, I'll do it for the one I noticed and add a task to add a CI step to find any others (and then fix those if there are any more)

SamWhited, yes, there’s a working attic ✏

I forgot to mention that there’s a script to copy changed XEPs into the attic, again based on xeplist.xml

awesome! So only the email bit remains an issue for now?

not really

I just want to test the tooling a bit more on real-world cases

then it can easily be integrated into the deploy step on the server

at least I think I fulfilled the wishlist I was given by Kev to make that happen easily

so, you're saying that both issues are well under way to being fixed?

indeed

Fantastic :)

more awesome!

Sam, I think you need to come up with a new list of things that aught to be improved :)

I'm going to pick up the kids

ttyl

Ge0rG: https://github.com/processone/ejabberd/commit/e1efd291568aae29ac06f507c8b0bbf60b65d91a

Ge0rG: there is another MSN-related bug reported by edhelas, hehe: https://github.com/processone/ejabberd/issues/2007

I'm keeping the ejabberd team busy these days

:D

edhelas: your bug is surprisingly harder to fix, unlike Ge0rG's one

due to shitty code of mod_muc

:p

zinid: thanks very much.

Holger: time to git-pull conversations.im! ;) ^ https://github.com/processone/ejabberd/commit/e1efd291568aae29ac06f507c8b0bbf60b65d91a

Ge0rG: Holger is working on this

he's busy porting his patches to this new ejabberd version (17.x is a lot different)

zinid I never report easy bugs, I prefer the tricky ones :p

zinid: What else than the pubsub patch?

mimi89999: are you about Holger? Stuff regarding registration and so on

Ah, the things really specific to conversations.im

yep

https://signal.org/blog/private-contact-discovery/

hm

nice, but not really applicable to XMPP, is it?

you’d still need to figure out which server to ask and you’d still need some directory trusted for mapping some_identifier -> JID

Oh yay, zinid is the best.

mimi89999: Yes conversations.im-specific things ... and dirty hacks :-)

We all love dirty hacks.

No we don't, and they stick around :( ✏