XMPP Council - 2020-02-12

It's the day.

it is

'tis nearly the hour.

that, too

dwd, are you feeling better?

Well, mostly the antibiotics now. But those stopped today, so should be normalish by tomorrow.

that’s good to hear

'tis time

1) Roll Call

I sense a Ge0rG

Hi

alrigth, that’s a quorum

2) Agenda Bashing

I note that I forgot about the of Bookmarks 2 which ends today, so we should probably briefly talk about that, too

any other additions?

None from me.

Here, just sitting down

Damn, I also totally forgot about Bookmarks 2.

3) Items for a Vote

3a) Issue a Last Call for XEP-0398 Title: User Avatar to vCard-Based Avatars Conversion URL: https://xmpp.org/extensions/xep-0398.html Nominated-By: https://mail.jabber.org/pipermail/standards/2020-January/036914.html Abstract: This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two. ✏

I’m +1 on that one

+1 for a Last Call. Fairly confident it can get through.

+1 for lc

+1 for LC

Sure, +1

\o/

3b) End of LC for XEP-0402

I think there was list feedback which should be addressed by the author.

I think there is feedback

There was list feedback, I shall address it if JC doesn't beat me to it.

even if no substantial changes are to be made, rationales for decisions need to be put in the document IMO so that they are discoverable.

But manageable feedback

so nothing to vote on from our side at this point, the editor will issue another LC once the update gets in

I'm mildly concerned that part of the feedback was adding password back in - so as author I'd rather see a second LC.

(Afterward).

also, the editor will change the title of the XEP with the next update, if nobody comes up with a better suggestion than "Atomic Bookmarks in Private PEP Storage" it’ll be that one.

dwd: because you will implement that feedback?

It's unclear to me what we do about the request from Flow to have sundry metadata included.

(sundry = unspecified diverse other things?)

Ge0rG, Yes, I think so - adding password back in seems to have general consensus.

jonas’, Yes, sorry. Generic metadata containment.

I vaguely remember having issues regarding backward compatibility requirements, which felt weeker than in 0411.

dwd, I think that the document needs to clearly say what happens to unspecified elements, since the elements pass through many entities

(and clients may "re-write" entries)

Indeed.

But all this can be sorted on list.

yes

let’s do that

Yes I didn't voice that on list (yet). But I also agree that password should be added

Even though I don't like passwords

Otherwise we simply don't have an upgrade path

4) Outstanding Votes

none that I know of

5) Date of Next

FWIW, it breaks on of my own rules of trying to impose things via a new protocol. Bind2 does the same in different ways and annoys me because of it.

+1W most probably won't work for me.

+1w wfm

+1w wfm

Ge0rG, noted, thanks

moving on

6) AOB

None from me

none from me, anyone else?

None

I'm pondering about better titles for 402

Atomic has a... nuclear ring to it

I really don't care about what we call it all that much. Though I'm apparently a lot more in favour of silliness than most.

I mostly think of std::atomic<T>

dwd, I’m in favour of peace, and this isn’t a hill for me (Editor) to die on ;)

maybe "Atomic bookmarks in PEP" does convey the best message

jonas’, Likewise.

We need to think of our target audience, which is developers

exactly

and it needs to be more attractive than Bookmarks.

we can blow this up. "Atomic Peer Metadata in Private PEP Storage"

Can we end the council session before bike shedding that?

Bookmarks 2 ✔️

I don't think that it is councils job

daniel, we certainly can

7) Ite Meeting Est

thanks everyone

<fin/>

daniel, I was trying to come up with a name that included bikeshed, indeed.

thanks everyone

the editor shall duely issue an LC for XEP-0398 now

Maybe "Bookmarks 2" isn't that bad after all. It has a clear and short message

XEP-0317: Hats

We need it!

jonas’: pedantic me claims that the LC for 0402 isn't over yet.

Ge0rG, so?

did I say it was?

Hm. No.

:)

I am aware that its end is very muddy

and I’d like to change the template, but that darn 14 day rule is making everything annoying

which template?

for LCs

the email template?

yeah

instead of "close of business" (in which timezone?!)

to something more clearly defined

Whichever timezone suits us, mostly.

(like 6h before the council session on $date)

fwiw, I don't consider any of our bookmark XEP bookmarks atm. They're syncing mechanisms as long as "autojoin" is in there

most of the things we do are syncing mechanisms

the roster is, for example

Right, but the 14 days means that we cover 3 weeks between Council voting for LC and Council handling the LC outcome.

MAM most certainly is

dwd, yeah, that’s kind of annoying

I’d like to make it 13 ½ days ;)

jonas’, I'd like to have a dumb JID/URI list that I can call bookmarks :( ✏

We're going to have other ways to sync anyway, see Inbox, or whatever else is coming

jonas’: but then you need to issue the LC right after the Council meeting, not the next day.

Ge0rG, which is *generally* not an issue

though, all of this is typically moot because most of the time we don’t agree on a LC in a single session

We generally agree on LC's. Not advancement, though.

maybe

sometimes people aren’t there tho