moparisthebestI think the reason good ux goes against security is because those are generally different developers
moparisthebestEspecially for web
emxpmoparisthebest: 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'
jonaswFLOSS needs more designers indeed
emxpand 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
edhelasyup I agree
zinidart can be learnt actually (especially graphics design, where you basically only need to pick right colors and shapes), but nobody wants to do this
jonaswI doubt that "nobody" wants to do this, there are quite a few graphic designers out there.
zinidjonasw: ok, I mean a typical developer
jonaswI 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).
jonaswbetter get an interested graphics designer involved
zinidhow will s/he join xmpp?
jonaswzinid, they don’t need to join XMPP to contribute.
jonasw(whatever joining XMPP means)
zinidcan you please describe the working flow of such designer?
jonaswI have no idea of designer workflows?
zinidI have :) I hired some back in the time
jonaswthen you can shed some light on it :)
zinidwhat I meant is that there should be incentive for a designer: money or interest
zinidsince s/he's not joined XMPP (not interested) only money left
ZashEveryone have their motivation sources
jonaswzinid, I don’t think that "isn’t part of XMPP" (still, whatever that means) implies "not interested" for sure
zinidin 15+ years of xmpp development I can barely remember as single designer
jonaswit can also imply "doesn’t know the key point which leads to interest yet" or "doesn’t know about XMPP at all yet✎
jonaswit can also imply "doesn’t know the key point which leads to interest yet" or "doesn’t know about XMPP at all yet" ✏
uc#Opensourcedesign on Freenet
jonaswzinid, that’s maybe because most of XMPP development takes place in the FLOSS community, where there are generally only few designers abound
jonasw(and what doesn’t take place in FLOSS often doesn’t announce XMPP that loudly)
ZashHave there been any studies on the general lack of designers in FLOSS?
jonaswZash, either there is a general lack, or they are mostly horrible ;-)
Zash90% of everything is horrible
emxpjonasw, 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
Ge0rGSo we need to acquire some designers...
emxpactually, whats the puropose of XSF? Do you collect money, too? For example, to pay people for specific programming/design tasks?
SouLI would say XSF cares about XMPP, the protocol.
SouLSoftware is a thing for developers.
zinidprobably collecting money and hire designers is not that bad idea
emxpSouL: maybe there should be an extended foundation or so. in principle like Google Summer of Code. but only for xmpp purposes
emxpi would donate money
emxpThis foundation furthermore could spend money on other things which supports xmpp too
zinidemxp: I think XSF has donations already
Guusexmp: 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).
Guuscopy/pasted that :)
Guusas 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)
zinidI 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)
Guusarguably 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)
zinidGuus: donating to XSF will not help xmpp in my opinion
Guuszinid: 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.
zinidGuus: I don't say XSF should do that
GuusWell, there are plenty of open source, but also commercial organisations, that do development on XMPP
GuusI'm sure that many of these will gladly accept help
GuusBy the way: most of the servers listed on our website are older than 10 years. There definately is a solid foundation there.
MattJProsody is 9
zinidI almost always talk about clients when I say "xmpp software" :)
MattJClient software is harder - platforms and UIs change
zinidno surprise we have some servers with commercial support, because it's easier to build bussiness model with them
MattJAll the 10-year clients around, people now call them ugly
Guuszinid: so, open up an IDE and start typing :)
ZashWrong shade of grey
Guusthere's a good deal of libraries available that you can (re)use to create new stuff
Guusbut you're absolutely right - we could really use more nice clients.
zinidGuus: I cannot do everything myself, obviously, I'm a server dev
Ge0rGI think that the XSF urgently needs to widen its scope from "protocol" to "software", so it can provide UX guidelines etc.
ZashRecreate the Jabber Software Foundation as a separate entity
Ge0rGZash: I've been pondering about that.
GuusOn first thought, I'd prefer that. Will have to give it more thought though.
Ge0rGZash: 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.
emxpGuus, 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
emxpor part-time in the beginning
ZashWhere'd the money come from?
Ge0rGBesides, I'm convinced that "protocol" also includes defining certain user-facing elements. Like how to call entity addresses for that protocol.
Guusemxp: 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.
zinidemxp: there is an initiative to collect money for Jingle support in conversations, it ended up with 500$ or so ;)
Ge0rGemxp: 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.
zinidnobody wants to donate
ZashSure there are people who want to donate, but you aren't going to get full time developer pay from donations
zinidtake a look at Matrix, they have funding problems and started fundrasing, the result is 2800$ : https://www.patreon.com/matrixdotorg
zinidand Matrix is quite hyped at the moment
Guuszinid: arguably, they _now_ have funding problems, because they started off as a fully funded project (which suddenly lost its sole sponsor).
zinidand Matrix has 11 developers, lol :)
Zash-do 2800 / 11
zinidwhat a bunch of money!
Guuszinid, what do you propose?
danielfor their london office this pays for the oyster card they need to get to work
zinidGuus: I would propose something if I knew, I see no solution
ZashSomehow attract people willing to spend their free time on making things better.
zinidor somehow attract their money
MattJCharge users $1/year for using your app
zinidMattJ: that didn't work, whatsapp was still unprofitable before the acquirement :D
ZashSell your soul to Facegoogle.
ZashAnd your users data.
zinidI have neither soul nor users data :(
ZashRaise money for a marketing campain in order to raise money for writing a client.
ZashMarketing marketing marketing!!
SouLUh, what do you want to do with me?
GuusSell you, obviously.
mathieuiSouL, sell you
ZashOne SouL, in mint condition, do I hear any bids?
mathieui09: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
ZashProjects dying isn't necessarily a bad thing tho. Something something Darwinism.
mathieuibut it’s bad because I’m the only one who updated the wiki after 2011
mathieuiso, "popular mobile clients" had J2ME and "popular clients" had coccinella
GuusIf we can't manage to update a wiki, I fear for development projects...
mathieuiGuus, that’s mostly because we had a very motivated guy doing it before then
GuusWhich, coincidentally, why I've started to help out with maintaining the stuff that we do have, as XSF.
Guusmathieui: perhaps removing outdated data is better than keeping it unmaintained. Nothing puts people off as much as seeing information that's clearly incorrect.
GuusI'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.
Ge0rGAre the json files used for client list generation hosted on xmpp.org as well?
Ge0rGWe are losing people everywhere!
GuusGe0rG: referring to the software listing? Yes, used for all software
Ge0rGGuus: not "used" but "hosted". The actual JSON files. So that external services could use them.
GuusGe0rG: that's my fear. The good news is that improving our data can be done by anyone. It's an easy PR away.
mathieuiGe0rG, that’s why I started that
mathieuithat and adding conversations, chatsecure, xabber
GuusGe0rG: Ah, unsure. Well, you could always refer to the stuff in Github, but I don't think it was intended that way.
Guusmathieui: thanks :)
ZashDid we update the Prosody file?
Guus"the Prosody file" ?
GuusProsody is listed on https://xmpp.org/software/servers.html, if that's what you mena.
emxpzinid: i siggest first lets ask, how many money can we collect. and how can we spend it. what needs to happen to increase donations
GuusGe0rG: 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)
zinidGe0rG: that's me yes
emxpGuus, 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
Ge0rGzinid: nice to meet you, and welcome to the XSF MUCs, where all the "inactive" members hang around :D
GuusGe0rG: 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.
Guus(That's where my distinction between Dev and Org originates)
Ge0rGGuus: that's probably true. Still, sponsoring individual devs/dev-orgs is out of scope for the XSF, and rightly so.
Guusge0rG: 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.
zinidyes, XSF should not collect donations
zinidit's pointless, they need to share them somehow between projects, that's hard
Ge0rGGuus: except there are no people who want to contribute significant amounts of money.
GuusSure it should. But not to sponsor one particular implementation.
zinidGuus: and how to share between the projects? on what basis? equally?
GuusGe0rG: All I'm saying is that the XSF need not be involved if someone wants to do sponsoring of individual projects :)
Guuszinid: you do not share at all. You use it for the activities that the XSF does itself.
Ge0rGGuus: yes. But the more important question is: how can the XSF contribute to a future where we do have non-shitty clients and servers?
zinidGuus: ah, ok
Ge0rGzinid: the XSF can still pay for Summit Dinners and XMPP stickers.
Ge0rGI wish we had Jabber stickers.
GuusGe0rG: 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).
Ge0rGa web frontend for this MUC would require developing a web client.
zinidregarding jabber tickers, isn't this XSF responsibility?
GuusGe0rG: 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).
zinidhow to post stickers?
Guusyes, the SCAM workgroup has stickers and leaflets and stuff, to be used in XSF activies like I described above.
Ge0rGGuus: the XSF is doing that for 15 years, and we still have shitty clients and servers ;)
GuusSCAM will (and has) happily send those out to people that are hosting such events.
GuusGe0rG: 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.
GuusGe0rG: 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.
GuusWe're already stretched - adding more work won't improve things.
Ge0rGGuus: indeed, you are right.
Guusas 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"!
SouLYes, that's true.
Guusit's just window dressing, but sometimes, that makes a difference.
Ge0rG"draft" isn't much better either.
Ge0rGSome XEPs live their whole life in "draft"
mathieuiGuus, what we need to do is either make the XEP status reflect real world perception, or add another status that does
mathieuiGe0rG, did I mention that 0059 is still draft?
Guusmathieui: I agree.
Ge0rG0045 is fifteen years now, and still in Draft.
Ge0rGThere are probably XEP-0045 implementing developers younger than that.
FlowThat's why I think we should find a better name for Draft before thinking about what to do with experimental
Zash"Work in progress", "Almost done", "Done" ? :)
Ge0rG"Broken", "Stale" and "Rusty".
FlowZash: Doesn't actually sound that bad
Ge0rGZash: replace the last one with "Carved in Stone"
ZashFINAL wait that's what it's called
MattJSkip that, jump to "Obsolete"
Zash"Living document" -> "Dead document"
MattJWelcome to the internet
Zash"Request For Comments"
zinidwhat I personally would like to see is how many implementations support the XEP, and probably range the XEPs in this order
zinidthis is only what makes sense, because even Final can be implemented nowhere
Zashzinid: Define support. Which leads back to the whole test suite thing.
zinidZash: claiming support is ok, even partial
ZashPretty sure Final requires two implementation.
Ge0rGZash: also goat blood sacrifices
ZashOr was it Draft?
zinidthis is final
zinidwhere is it implemented?
ZashVersion 2.0 (2002-12-09)
Per a vote of the Jabber Council, changed status to Final. (psa)
SouLCould 'Subject to changes' be used for 'experimental', for example?
SouLOr we should use just a word?
zinidSouL: I think every XEP should be "subject to changes", we have namespace bumps
zinidthe only difference is probability
zinidso "in development" and "more or less stable" is enough
ziniddunno why there so many gradations
ZashExperimental = "In active development"
zinidstill says nothing for me, I need to see where it's implemented
ZashWhen it stops being in *active* development it goes into deferred
ZashSimilar to how IETF drafts expire after some months.
ZashShould the XSF try to keep track of implementation status?
zinidI don't think this is a lot of work
zinidonly creating some form
zinidwhere everyone can submit
ZashPeriodic calls for experience?
zinidno matter, something that would work without tons of pain
Ge0rGWhat about a "compliance badge" that can be assigned after completing the compliance suite.
ZashMaybe when things go deferred, send out a survey thing asking if anyone has been working on an implementation?
Ge0rGThis client fulfills [Jabber Gold Premium]
GuusI've just posted on standards@ about the XEP status name change. I'm interested to see what others think of this
Guuswith that, I'm disappearing into the world of managers, deadlines and stale coffee.
MattJDon't do it!
zinidZash: "send out a survey" <-- where to send it?
Ge0rGMandatory JIDs everywhere!
ZashThe standards list
zinidI think not so many people are in active conversation with XSF (list, chatroom, etc)
zinidI almost never see Gajim devs in the list
zinidmaybe they are here?
ZashActually, I think the core of the proposal is to send out a call for experience along with the deferred message.
zinidnah, I was suggesting to track the number of implementation right in front of XEP title or so
Ge0rGSounds like a task for a web service.
ZashFiguring out if a XEP became inactive because everyone already implemented it or because nobody implemented it would probably be good.
Ge0rGZash: isn't that what "Final" vs. "Obsolete" is for?
ZashGe0rG: It's "Which direction should this Experimental XEP go?"
goffididn'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.
zinidGe0rG: a really simple submitting form is enough, which will put numbers in the database for displaying, I don't think this is brutally hard
ZashThere exists survey tools, if someone wants to automate it that way.
Ge0rGzinid: web forms will be immediately overrun by spammers.
zinidwell, using existing tools is preferable of course
zinidhow others do this, cannot imagine
Wiktorfor the record, tracking progress for OMEMO is one github repository: https://omemo.top/
ZashCould 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
mathieuizinid, gajim devs are not in there, no
zinidthat's pitty because this is one of the most popular desktop client (although not everyone like it)
zinidand we don't hear their opinion
Guusso, get them in here :)
goffimathieui: Asterix is writing from time to time on @standard
zinidwe cannot force every developer joining this room or the list
GuusMake them an offer they cannot refuse ;)
mathieuithe issue with gajim devs is that they really are busy (it’s mostly lovetox these days, with asterix showing up from time to time)
zinidwhat I want to say is that we shouldn't expect lots of responses from developers and drawing conclusions based on received responses
Ge0rGzinid: do you have a better proposal?
zinidGe0rG: tracking existing implementations is a good start in making some decision (such as deferring for example)
edhelasmaybe we could first track what XEPs are implemented in which clients
Ge0rGzinid: but how?
edhelasit's not that hard https://nl.movim.eu/?about#caps_widget_tab
zinidGe0rG: are we going circles? :) submitting form?
zinidthe point is everyone can submit
zinidso even if developers are busy their users can submit
zinidanother advantage is of course everyone can decide about XEP popularity by implementations number
zinidinstead of experimental/draft/etc nonsense
ZashEveryone implementing something doesn't make it good.
ZashGood things don't usually win popularity contests in my experience.
zinidreally? in the context of standards?
zinidwhich means the standard is crap? :)
ziniddo you remember such situation in xmpp?
mathieuiedhelas, caps widget is not enough
ZashGood enough combined with timeing on the other hand.
edhelasthe issue is, more than asking dev to be aware of new XEPs, is also to push them to deprecate or remove old ones
edhelasmam:tmp, vcard_temp, Private XML…
Zashvcard-temp and private xml are good enough, but not really that good
ZashMultiple versions of the same XEP is a somewhat different issue.
jonaswgoffi, 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.
jonaswzinid, if users submit on behalf of their software, we’ll be getting incomplete and inaccurate data, that’s worse than no data.
jonasw(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)
zinidjonasw: why would we have inaccurate data?
zinidI don't say it would be 100% accurate
Ge0rGzinid: because users are clueless.
jonaswwhat Ge0rG says
Ge0rGzinid: it would be 40% accurate and there would be multiple submissions.
zinidGe0rG: a clueless user who knows what xsf and xep is?
Ge0rGUser often already fail at spelling a client name correctly.
ZashIf clients put XEPs into their marketing, then users will be somewhat aware of them.
jonaswGuus, regarding donating money to client organizations: there are enough clients out there which do not have an umbrella organization
zinidthen what makes you think a developer is responding on your last calls?
jonaswsome of which are doing great work in the UX department (I heard dino is nice)
jonaswaccepting donations is tricky
Ge0rGI'm working on a system for people with technical background, and they fail to properly spell their own name.
zinidmaybe that's a clueless user responding
jonaswzinid, you got me thinking that we sohlud probably issue CFE and LC to the developers list too
zinidjonasw: you need to find developers there first :)
Ge0rGzinid: 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!
zinidGe0rG: sure, and you go develop ejabberd
jonaswerlang vs. web development
goffijonasw: 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
Ge0rGzinid: sorry, I've got my own client to develop, and I'm submitting issues for a bunch of others.
goffiand they are deferred
goffianyway I now need to update them so it's not a big deal.
jonaswgoffi, if there are two implementations, you should ask for advancement to Draft.
goffijonasw: now, because I need more tests
goffitoo early for that
Ge0rGzinid: 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.
Guusjonasw: 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.
jonaswGuus, it is massively tricky if you are employed elsewhere
jonaswI 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.
jonasw(maybe that’s only a german thing that these things are complicated)
zinidGe0rG: 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
Ge0rGzinid: I'm not the server operator, so I don't have logs.
Guusjonas: 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.
jonaswGuus, I don’t even know how such a clause would need to look like, really.
Guusperhaps we could facilitate that planning in some way, shape, or form - simply by letting people interested get in contact with people with experience.
zinidGe0rG: I can only say I will check if I don't forget (like always)
Ge0rGzinid: also you seem to have enough time to make proposals here and on standards@ .P
zinidGe0rG: nice try :)
Ge0rGzinid: you know, I've once waited multiple years on an ejabberd ticket. Then I gave up and switched to prosody.
Guusjonasw: 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.
GuusI might've been lucky, unsure, but it always worked out.
zinidGe0rG: and now waiting years on prosody tickets, ok
Guus(and it has the added bonus of having HR work out the details of the clause :P )
jonaswGuus, right, will take that into account when I get my employment contract soon-ish
mathieuiGuus, 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
SouLI thought they would do that only in the USA
Ge0rGzinid: EJAB-532 took four years for a community workaround. I've got two more years to go with prosody before reaching that timeout.
Guusmathieui: I don't recommend knowingly accept a contract and disobey it, even if it's an invalid contract.
Ge0rGGuus: sometimes that's better than not having an income.
Guusi've always had my feedback on a contract draft addressed by HR - but again, that might be lucky.
zinidGe0rG: so what is your conclusion? every ticket takes years to resolve? this is not true of course, you can check dynamics on github
GuusGe0rG: I was assuming that it wasn't even discussed before signing it.
GuusGe0rG: if it *was* discussed (but still disallowed), then I'd more so advice against breaking it!
Ge0rGGuus: 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.
GuusGe0rG: I might have been lucky with my employers then. Might be a cultural thingy difference between the types of organisations we work for.
danielAnd this is what happens if you don't have unions
jonaswdaniel, does conversations.im already have a union? :)
Guusthe boss wouldn't allow it! ;)
Ge0rGdaniel: don't go Set Theory on us!
Ge0rGunions, intersections, etc.
jonaswnow we’re at traffic managment!
mathieuibangs the on-topic gavel
jonaswmoves out to xmpp@
Guuswho can give SCAM-wg access to the XSF twitter account?
goffimathieui: 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.
goffimathieui: 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)
pep.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
edhelaswell depends to who you're doing "marketing"
edhelaswhen 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
ZashGo to various clients web pages, search for XEP, count matches.
pep.I'm not talking about devs, nor poezio (console client) users
Ge0rGI think there was recently a proposal for a formal client description language, including XEPs.
jonaswthat’d also work for gathering implementation stats by the way
edhelasjonasw are you talking about https://github.com/movim/moxl#xmpp-support or https://github.com/dino/dino/wiki/Supported-XEPs ?
jonaswgoffi, care to reply to daves email on standards@ with your example?
jonaswI think it’s relevant to the discussion
dwdgoffi, '355/356? If they "don't need updating", then they're surely ready for advancement?
mathieuidwd, "I now need to update them"
goffidwd: 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.
dwdEither 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?
goffidwd: 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.
SamWhited> 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.
dwdSamWhited, I don't even know what you['re quoting, and I agree.
SamWhiteddwd: Yah, those words were said earlier (about something that I suspect editors would end up having to do).
SamWhitedIt 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.
SamWhitedBut it applies in general too.
dwdSamWhited, 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).
SamWhiteddwd: Indeed, it needs some love.
dwdSamWhited, 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.
SamWhiteddwd: I agree
jonaswdwd, the question is whether that lack of understanding comes from lack of documentation, lack of active education or something else
jonaswin 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
dwdjonasw, 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.
dwdjonasw, 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.
SamWhitedActually, 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.
Kev"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.
Kev(Actually, that's not true, we try not to in ways that are backward incompatible)
dwdSamWhited, 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.
SamWhiteds/that might/that are likely to/
SamWhiteddwd: 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.
dwdKev, 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.
KevI think 'Not obviously stupid and not duplicating existing stuff with no clear differentiator' is the check I used to do for +1ing Experimental.
Kevdwd: Changing the required namespace is about as backwards incompatible as you can get.
KevWhen talking about compatibility of the document, not of a particular namespace within it.
dwdKev, Well, sorta. The old namespace still works, nothing is broken. But yes, it's a clean break rather than maintaining interop.
SamWhitedAdded a card for board to discuss the rename.
SamWhitedAnd one on council to make a recommendation.
Guusrenaming draft to stable and striving to not keep things in 'experimental' for to long would be big wins, I think.
Guusif, on top of that, we can apply structural simplifications to the entire process, even better. Suggestions?
jonaswI’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)
Guusjonasw: but you fall in Sams 'new-and-not-yet-burned-out' category :)
jonaswthe level of automation helps against burning out though
jonaswneeds moar autmoation though
ZashAlways moar automation
jonaswI need to figure out how to make a github bot which can post metadata of all touched XEPs in a PR
Guusabsolutely, but automation needs maintenance too.
jonaswit is annoying to have to look up the status and authors of a XEP manually inside a diff
GuusI'm heading out again, but I'd be very interested in hearing practical improvements that we can make to the process.
jonaswsomething which detects when a namespace bump must happen would be amazing
jonaswbut I doubt that’s possible
jonasw(maybe something which warns when RFC 2119 words are touched)
KevWhich doesn't imply that it needs a namespace bump.
jonaswbut it’s still something good to see quickly when processing a PR
jonaswI’m bad at reading diffs
Zashjonasw: Any diffs or XEP XML diffs in particular?
jonaswZash, XEP diffs are especially bad because of long lines
SamWhitedI can read diffs fine. I can barely read XEP XML when it's not a diff.
jonaswor alternatively, because of line-broken text
ZashAnyone wanna continue my work on turning xeps into text/markdown for simpler diffs?
jonaswZash, dump the code somewhere, I may take a look
jonaswdoesn’t help much when viewing diffs on the repository online though
SamWhitedJokes 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.
SamWhitedWhich is a long way of saying what jonasw just said
jonaswI’m not sure how I said that
SamWhited> doesn’t help much when viewing diffs on the repository online though
jonaswwell, 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
jonaswI 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.
jonaswZash, can you dump a quick list of todos below that?
Zashjonasw: I think the main blocker for me is that I don't know how to proceed, or what to do with it.
jonaswfrom what I can tell it converts xep-xml to markdown, right?
ZashThe 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.
GuusSamWhited, so what _does_ help?
SamWhitedGuus: What does what help?
GuusYou 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.
SamWhitedGuus: 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
SamWhitedSome of them have been done, it's definitely a bit nicer now
Guusif there are sensible improvements left, by all means, lets implement them.
Guuslet's put things on the radar of those that are to decide on things.
SamWhitedThe 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)
Guusah, okay, that's automation. I though you were referring to procedural changes (eg: make XEP-0001 less complex, or something in that nature).
ZashA thing that I've wondered about is, is there a good way to XEP versions to commits?✎
SamWhitedOh I see, sorry
ZashA thing that I've wondered about is, is there a good way to map* XEP versions to commits? ✏
Guusnot to say that the automation bit wouldn't be wildly helpful.
SamWhitedZash: 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.
SamWhitedSo maybe we need to improve CI as well
GuusSamWhited: maybe it's worth manually revamping those XEPs, for the greater good?
SamWhitedGuus: 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)