jonaswI’d like to add "Revisit BMH in the context of Styling" on the Councils agenda for today, but I don’t want to abuse my editor powers to do so, so I’ll just drop this here.
danielwhen (and by whom) was this vetod upon? I can't find the minutes for that
jonaswbut I don’t see rationales
ZashDoes that mean it was actually accepted?
Ge0rGNo, -1 is a veto
ZashI'm trying to figure out if a rationale is required :)
Ge0rGI'd be surprised if not.
KevIt is required that anyone vetoing provides a rationale, but a rationale isn't required to veto :)
jonaswI am confused, Kev.
ZashI can barely parse that sentence. I blame the coffee.
Ge0rGMe neither. And I've got enough coffee to rule out that source of confusion.
ZashThe word "veto" isn't in XEP 1
Zash"object" it says
Ge0rG"confusion" can also result if you remove a substring of "coffeine infusion"
jcbrandGe0rG: unfortunately in English it's caffeine
Ge0rG"confusion" can also result if you remove a substring of "coffee/? infusion"
Zash> If objections are raised by the Approving Body on the Standards list or in its meeting, the XEP author is encouraged to address the feedback of the Council and to submit a revised version of the proposal and/or confer with the XMPP Extensions Editor or objecting Approving Body member(s) regarding how to proceed.
KevAnyone vetoing a protoXEP needs to provide a rationale, but that doesn't mean that failing to do so magically accepts the XEP.
jonaswKev, that makes more sense, thanks.
Ge0rGSo SamWhited is currently in violation of XEP-0001...
jonasw(so is Link Mauve, I think, at least on the list record I can’t easily find a rationale)
Ge0rGDamn, so I've violated 0001 as well.
Ge0rGjonasw: <Link Mauve> I’ve already read it yesterday evening, and I’m very much -1 on it due to the concept of waiving any format support, forcing implementations to support multiple formats and making it impossible for a message to carry more than one (think MUC for example).
jonaswGe0rG, that’s not on-list unfortunately, but good to have
Ge0rGjonasw: it's in the logs.
Link MauveHi, it’s time.
Link MauvePing Tobias, SamWhited, dwd.
TobiasLink Mauve, you want to run the meeting?
Link MauveI can do that yeah. :)
SamWhitedoops, I am still confused and thought it was in an hour. I also am here though.
Tobiasgo ahead :)
Link MauveSo 1) roll call.
Link MauveEveryone’s here.
Link Mauve2) any minute taker?
SamWhitedTobias: grooming Link Mauve for command I see!
Link MauveAnd https://xmpp.org/extensions/inbox/markup.html
Tobiastrello just mentions one of them
Link Mauvejonasw sent the second one yesterday, maybe we forgot to add it.
dwdThis is the next meeting for both, so we should properly consider them now.
Link MauveIt has had a proper announce email anyway.
TobiasLink Mauve, but we probably want to vote on each individually, not?
Link MauveWith these proposals, I’m finally happy with deprecating XHTML-IM, it seems jonasw took into account every criticism I’ve seen on the mailing list in all threads that have been talking about it recently.
Link MauveTobias, sure, but we will vote on them next week.
dwdLink Mauve, I don't follow - vote on what next week?
SamWhitedDon't we normally vote in the first meeting after a submission (or on list, of course)?
Link Mauve(IIRC we have two weeks to vote on accepting a ProtoXEP, I can start the vote right away if you prefer.)
dwdLink Mauve, Two weeks to vote, starting at the next meeting.
dwdThis being the next meeting.
Link MauveSo let’s start.
Link Mauve4) Vote on styling.html
Link MauveOn list.
Link Mauve5) Vote on markup.html
dwdSamWhited, You say naturally but XEP authors have voted against their own XEPs in Council before, you know.
Tobiason list, haven't read that one yet
SamWhiteddwd: I'd love to hear the story there
dwdI'm +1 on this too. I don't think I want both, ultimately, and would prefer the other, but I'm not going to die on this hill if I can avoid it.
Link MauveThe other one has seen a lot of criticism, before and after the proposal (it basically ignored most of the arguments against this approach), this one has only the downside of OTR and such not playing well with it; arguably OTR already has its own styling mechanism (it carries HTML).
Tobiasyeah. I think we shouldn't let restrict us by ancient OTR
dwdLink Mauve, It is possible to take notice of arguments without agreeing with them, you know.
SamWhitedAlternative take: most of the critisism was addressed and the responses were ignored, but maybe this isn't the time and the place to be throwing statements like that around.
Link Mauvedwd, of course, but it ignored all of the arguments against Markdown not to name it.
Link MauveAnyway, let’s move on.
Link Mauve6) 0146 obsoletion.
Link MauveThis has happened since last week, so I just archived the card.
SamWhitedSorry for the delay on that
dwdLink Mauve, No, I'm not comfortable moving on when you're accusing others of *ignoring* arguments raised.
Link MauveSorry, 5) again.
dwdLink Mauve, That's a very different accusation then asserting that the author has chosen not to agree with, or address, the arguments in the spec.
SamWhiteddwd, Link Mauve: this is the second time something like this has been brought up recently. I certainly don't think I ignored the arguments, just disagree and addressed why I disagreed, but since obviously multiple people feel that I ignored them I can try to address it on the list again if you want.
jonaswdwd, I think if arguments are heard, they should be in a rationale in the XEP, which Styling may or may not have done.
Link Mauvedwd, reading both the XEP, the mailing list, and xsf@, I haven’t seen most arguments addressed.
SamWhitedHowever, it would be more helpful if I had a list of specific things that you feel were ignored and then I'd be happy to address them (either in the XEP or on list)
jonasw(I added a sectino "Design Considerations" to my XEP-0392, which I think is a good way to do that)
Link MauveI think both XEPs should contain a strong rationale about why they are designed that way.
Link MauveSamWhited, I can make such a list, I’ll add that to my TODO list.
Link MauveThere were already somewhat-summaries on the mailing list, I’ll use these.
Kevjonasw: I think addressing every on-list discussion in a Rationale section's a jolly bad idea, FWIW.
dwdLink Mauve, FWIW, I do not wish to set any kind of precedence that every argument raised against a XEP has to be documented in the XEP.
KevYes, this would be horrendous.
KevElse I want every XEP to document that the protocol isn't pink enough :)
dwdLink Mauve, And having raised this argument, but those rules you'd have to document it in every XEP.
jonaswsure, but if arguments are brought up multiple times and are well reasoned, I don’t see why not.
jonaswI’m fine if people say my arguments aren’t well reasoned, I’d like to know why though :-)
danielmessage styling actually addressed a lot of critisms. for example we agreed on leaving the keywords in. get rid of the disco feature and so on
Link Mauvedwd, indeed, that sounds like a bad idea, but it would be useful to have a short list of alternative approaches and why they weren’t taken.
Link Mauvedaniel, oh? Did it change since I last read it? I remember it letting the receiving client do whatever it wanted with the rendering.
SamWhitedI made promises to change it, I didn't want to merge until it was accepted
jonaswLink Mauve, the ProtoXEP wasn’t updated, but people agreed to change it
KevWhich is the right thing to do, incidentally.
SamWhited(unless of course one of those changes is blocking acceptance)
KevWe shouldn't be mandating rendering :)
Link MauveWhich confirms my “on list” vote for 4). :)
KevFWIW, I would recommend that if one of these two XEPs are temporarily blocked, both should be :)
KevBecause they seem to be a pair of competing proposals that should be considered together.
Link MauveSounds fair, they both are as of now.
jonaswKev, I personally am not seeing it that way (anymore).
Kev(Although this is counter to my desire to get stuff published ASAP so it's under XSFness, so ... yeah)
Kevjonasw: You might be in the minority :)
jonaswI think both can serve a very useful but distinct purpose each. And I think that we need BMH back.
jonaswbut I guess that discussion has to wait until next week if not everyone has caught up on the list yet
jonaswI proposed to add reconsidering BMH to the agenda for today, not sure if that was seen?
danielso wait just to be clear and that we don't end up dead locking here. Link Mauve you want SamWhited to make those changes before you +1?
Link MauveI would be totally happy with revisiting my vote on BMH with compelling arguments, fyi.
danielbecause if SamWhited waites until this is approved this will dead lock
KevIf already-promised changes are the only thing blocking, I think just taking it on Sam's word that he'll update would be fair. Personally.
Link Mauvedaniel, no, I haven’t fully caught up with the mailing list, I’m only based on my first reading of his XEP.
Link MauveOf course I wouldn’t block anything due to changes not having been pushed yet.
jcbrandJust to be clear concerning the minutes, BMH was a previously proposed protoXEP that wasn't accepted right?
Link MauveYes, Flow’s one, about annotating which markup the body is formatted with.
SamWhitedCan we hold off on revisiting that one until next week since it just got brought up?
SamWhitedI haven't had a chance to think about how that would interact with either of the new proposals
dwd(I think, having been rejected, that it would need resubmitting for IPR purposes).
Link MauveOf course, your ProtoXEP changes how it could interact with the ecosystem.
Link Mauve(That’s a detail, I’m sure Flow would be happy to do so. :))
jonaswSamWhited, to be clear, I’d argue that Styling should get a BMH hint-namespace-thing
danielfwiw i don't think we need bmh for the opt-in approach to message styling that jonasw proposed
Link MauveI haven’t read that part yet, so I’ll abstain for now.
jonaswI agree with daniel, but I see merit in the general idea of BMH, following the argument Flow gave when proposing it
jonaswbut moving this to next week until everybody has had time to consider all the XEPs seems very reasonable to me (not that I’d have any say in that)
KevI think what we actually need is an opt-out, but I need to have time to reply sensibly, and this is team appraisals week.
SamWhitedI think I agree with what Kev said, but I'm not 100% sure yet about the idea of hints in the styling xep.
danielyeah maybe opt-out is more sensible
KevI think what you want is
for lots of thinsg.
danieli can live with both though
KevAnd that applies both to styling and to emoticons.
Link MauveKev, oh yes, sounds great.
jonaswI still think we shouldn’t impose this on clients which don’t want that.
dwdjonasw, That would be *terrible*.
SamWhitedIs this something people feel they need to make decisions on voting right now? If not, can we discuss specific details after the meeting? I want to make sure we get to everything before I need to leave for standup
Link MauveIt still breaks existing simple clients, such as bots.
KevUsually when people disagree with me it's because they're clearly idiots, but I think in this discussion there are reasonable arguments on multiple sides.
SamWhitedKev: I disagree.
SamWhited(sorry, couldn't resist)
Link MauveSamWhited, we can discuss on list/in xsf@.
KevSamWhited: That would be one of the other cases.
Link MauveSo, 7) AOB?
dwdLink Mauve, You don't want to obsolete '146 anymore?
Link Mauvedwd, it’s obsolete already.
Link Mauve6) was super quick. :)
dwdNo AOB from me then.
Link Mauve8) Date of next.
dwdWFM2. How many more meetings do we have? Two?
Link MauveTwo yes.
Link Mauvebangs gravel.
Link MauveThanks everyone!
Link MauveBtw, thanks dwd for sending chat states, it really helps to know who is going to speak next.
Link MauveI wish every other council member would do the same.
Tobiasthanks Link Mauve for running the meeting, thanks jcbrand for the minutes
TobiasLink Mauve, my client doesn't support that
SamWhitedWhew, we survived the styling meeting :) thanks all!
KevSamWhited: Are you *sure*?
dwdLink Mauve, Well, here's the thing. Gajim sends them, but doesn't render them.
Link MauveTobias, I know, you should push for that then, it’s extremely useful during a meeting.
moparisthebestso far, I'm still waiting for the xmpp fork of 2017 due to styling
KevLink Mauve: No-one's going to push back on it.
SamWhitedMcabber doesn't support anything… but it does do Vim style keybindings, which is really all I want in a client.
dwdmoparisthebest, You'll *never* be able to read messages again.
KevI've been saying I'd like this for ages, we've just not done it yet.
Link Mauvedwd, ah yeah, I provided the patch to send them, I don’t know if any other contributor wants to display them yet.
Link MauveKev, maybe I could contribute that then. :)
dwdKev, Our new client does, but I'm not using it yet (it's a little simplistic). Probably good enough for MUC meetings, though.
Link MauveAs of today I’m now unemployed, I should have more time to fix the world!
KevLink Mauve: If you want to send in a patch for send/render CSI in MUCs, it would be gratefully received (subject to normal patch things).
Link Mauve(Of course.)
SamWhitedLink Mauve: Unemployed, or Funemployed?
jonasw(where’s the difference?)
Link MauveSamWhited, heh, doing things for myself, with myself as the drive, and myself as the client. :)
SamWhitedNice, I'm jealous
moparisthebestdwd, hmm gajim colored your whole message to me red and bolded the whole thing, hence, I have no idea what your intention was
danieli should write a gajim plugin that always randomizes the color in the xhtml variant of the message
Ge0rGdaniel: randomizes the color of each letter in the message.
Link Mauve/load rainbow
danielits called syntax highlighting
danielnouns red, verbs blue, adjectives green and so on
jonaswdaniel, looking forward to a piece of software which gets this right!
dwdjonasw, Stanford released some OSS code to do that in Java a while back.
SamWhitedAn extension to replace all messages with the results of <messagebody> | cowsay | lolcat
jonaswaww, lolcat doesn’t install
Link Mauve __
_ / /
Link MauveHey, just like Yaxim and Conversations display single emoji bigger, poezio could do so with figlet!
jonaswfiglet fails at utf8.
Link MauveI know. :(
SamWhitedI can see that working well for all messages in Gajim.
jonaswSamWhited, | figlet!
SamWhitedcowsay and figlet don't play well together
jonaswalso, that’s kindof the point
SamWhitednot on my machine; maybe there are options
jonaswit looks weird for sure, but it produces sensible output
jonaswah ok, it breaks with long messages
Ge0rGLink Mauve: take the Google NoTo Emoji font and render its SVG into the flickering avatar square
SamWhitedWould anyone be against me making a few slight changes to the styling XEP that don't actually affect anything before it actually gets published? I figured I might as well go ahead and commit some simple editorial changes (typos, definitions, etc.) that I was going to make assuming its accepted (since they're already done, I was only holding off on the larger changes because I didn't want to waste time if it didn't get accepted)
jonaswSamWhited, editorial changes etc. seem fine to me
SamWhitedyah, me too, I just want to make sure the people voting don't have any objection
KevSamWhited: Was it accepted?
SamWhitedKev: one remaining vote on list
KevIf it's not accepted, there's no issue updating the protoXEP. If it's accepted, you don't need Council approval to make changes to an Experimental XEP of which you're the author.
SamWhitedgood point, I guess I could make them anyways.
KevSo while *technically* you should publish the version that was approved, I don't think it's going to hurt much.
jonaswFWIW, I’ve been holding back editorial changes etc. until after approval too
danielYeah just update it
moparisthebestI haven't heard a single person argue it should be kept as-is so
SamWhitedI ended up pushing some of the simple non-editorial changes too: https://github.com/xsf/xeps/pull/537
SamWhitedStill more to do, but that was all the simple stuff that didn't require a lot of work or that I already had done, plus I tried to clear up a few things.