XMPP Council - 2024-11-26

One hour till our meeting

👋

It’s time

1) Roll call

Ahoy there, council members!

hi

I’m taking the liberty to chair this meeting until we elect a new chair in a minute

sure

singpolyma, are you around too?

Here

2) Agenda bashing

nothing to bash I assume?

Nothing

3) Elect new Chair

if I have your trust I would actually like to continue doing my. having editor and council chair being the same person has turned out to make things very efficient imho

that doesn’t mean we can’t have other candidates of course

+1

+1

+1

+1

Having watched you do it for a year, I'm pretty confident that I couldn't 😀

Thanks for volunteering again daniel

ok. awesome. thank you all for your trust.

moving on

4) Editors update

* NEW: XEP-0496 (Pubsub Node Relationships) * NEW: XEP-0497 (Pubsub Extended Subscriptions) * NEW: XEP-0498 (Pubsub File Sharing) * NEW: XEP-0499 (Pubsub Extended Discovery) * Proposed XMPP Extension: MUC Slow Mode

a bunch a pubsub xep. I hope i didn’t miss any :-)

5) Items for voting

a) XEP-0490: Add the XML Schema and fix some examples https://github.com/xsf/xeps/pull/1400

+1

+1

+1

+1

+1

b) Proposed XMPP Extension: MUC Slow Mode https://xmpp.org/extensions/inbox/xep-slow-mode.html

-1

+1 needs some work but this is what experimental is for

+1 . I have a few remarks I'll post on standard@, but it's good enough for experimental.

+1, definitely a feature that is desirable

+1 - even if it doesn't have a schema 😀

singpolyma, do you want to say why?

I think my concerns are outlined on list. It's too narrow a use case imo especially when we know from experience broader use cases are needed in practise

Can't this be modified during experimental cycle?

I saw the use case listed and thought 'I bet there are others' - but wouldn't experimentation find those?

Sure, anything can be. Not a reason to let it in imo just because it could be changed later

My point is some of these are already known. We don't need experimentation to find them the experimentation is ongoing

imho this covers a use case that is available on major video streaming platforms. just because there are somewhat related other uses cases doesn’t mean we as a community can’t experiment with a xep that only covers this particular use case

I think it's important to explain to the author why you veto and encourage new version. I think that it's a new author, and there was some though put in this + apparently and implementation for Peertube. Would be good to encourage them. ✏

I think it's important to explain to the author why you veto and encourage new version. I think that it's a new author, and there was some effort put in this + apparently and implementation for Peertube. Would be good to encourage them. ✏

goffi: their implementation is great initiative. They don't need a xep for that

I think it's important to explain to the author why you veto and encourage new version. I think that it's a new author, and there was some effort put in this + apparently an implementation for Peertube. Would be good to encourage them. ✏

and fwiw youtube doesn’t have burst either. which I admit is a bit annoying when you first run into that as a user. and then you learn to type full messages. instead of hitting enter after each sentence

but anyway let's move on for now

The point of adding a xep would be. I mean with this kind of xep I'm not sure. To encourage clients to add special UI for the form field?

A counter on the client side would be useful UX.

(i think clients would tell users that the mode is enabled precisely because they know that they need to type in full sentences because they don’t have burst)

A counter? I'm not sure this xep has what's needed to implement that?

Also you might get the server implementations

so it's not just about the owner enabling it but also the user knowing

I think burst can be easily added to the XEP, but it's certainly not a requirement for it to be useful. XEPs don't need to be perfect from the beginning

the youtube 'client' tells you when slow mode is on

Fine. If you all feel strongly I can change to -0

singpolyma: the XEP mention counting in "client handling"

c) Make Daniel (co-)author of 'XEP-0343: Signaling WebRTC datachannels in Jingle' https://xmpp.org/extensions/xep-0343.html

+1

+1

(and I'm really happy to see movement on this XEP)

i've tried reaching out to the auther but the email address doesn’t work anymore

I'm very pro adding authors if a xep is stuck

goffi, yes it's been a year since larma and I worked on that thing. but it's now fairly up on my todo list to actually modify the xep

+1

great :)

+1

I don't think this came up in the last council

A non-author can't propose changes, so you want to be author so that you can?

I want to make changes and apply them directly to the xep

dan.caseley, everyone can propose changes on experimental XEPs, but they need an author to be accepted.

during experimental changes need author approval

but if the author is gone we need a new one

+1

usually you can ask the author directly (marvin did this 1-2 times last year)

but obviously not if the email address doesn’t work anymore

Are you sure that's true?

which part?

That only an author can approve changes in experimental.

it's certainly how we have been running things for a while

There are several things that authors do around advancement, addressing feedback in LC, but I'm not 100% sure that gatekeeping changes is in xep1, just that Editor has always asked the authors because committing changes when an active author is opposed would be weird as a default state.

> The XEP author (or Document Shepherd) is responsible for collecting feedback from the XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal.

Indeed, which is related but not quite the same.

Anyway, this is possibly academic, as a XEP with no Authors is zombie-ish.

Oooh, process thing. So the documented process is that only the author actually makes changes, so if someone else makes a change that's either not documented process, or they become an author, or...?

it certainly doesn’t feel wrong to ask council to assign new shepherds. even if not strictly needed

> Oooh, process thing. So the documented process is that only the author actually makes changes, so if someone else makes a change that's either not documented process, or they become an author, or...? Can you find the bit of xep1 that says that? I can't, at quick grep.

anyway we have a 30min time limit so I'd like to move on

6) Pending votes

none yet

please check if you can all access the google doc from the agenda email

Kev, The bit larma quotes implies it. It's not clear though, and something we should fix.

7) Date of next

+1w wfm

+1w wfm

I can read the spredsheet yes.

+1w wfm

next week I'll be travelling to attend an event in Paris, I not sure if I can attend, I'll try to be on the phone.

8) AOB

+1w wfm

assuming none

I have a question: do we have an pad or something to prepare agenda? How to we ask to add an item to the agenda?

9) Close

No AOBs, other than - should we ask Board to look into that Authors & Shepherds thing?

goffi, ping me (chair) in here

dan.caseley, On it anyway.

or email

Thanks dwd

OK, and can somebody change the subject in this room to reflect the new meeting time?

that btw goes for everyone. not just other council members

done wrt subject

great thanks

daniel, Probably want to remove the URL there, too.

FWIW, that bit of text doesn't just say making changes, but collecting feedback. I'm assuming we'd not claim that people other than the author aren't allowed to collect feedback on the XEP? :)

9) Close. thank you all. let's discuss process things after the meeting

thanks daniel.

Sorry, I thought you'd already done > 9) Close so I continued.

Kev, Responsible for collecting, which seems clear enough, and responsible for incorporating, too.

honestly this happens infrequently enough that I personally don’t really care. when larma took over they asked the previous author to approve a change that also added themselves as an author

Kev, Not that I'm saying it's very clear, or indeed what we would want even if it was.

So if it means that no-one other than the author is allowed to incorporate feedback, it must mean also that no-one but the author is allowed to collect feedback, and I find that frankly bizarre.

which basically circumvented this issues without involving council

I read that text as saying that the Author must do these things, not that no-one else may.

when I officially became author of Display Marker a million years ago there was a council vote too

Kev, Which is fair. So the real question is what is the process that's actually followed right now?

Kev, And that seems to be that a XEP in Experimental is "owned" by the author, and that can only change with the author's permission or the Council's decision.

De facto process is that Authors are whoever submit, and whoever they choose to add, only authors may approve experimental changes, and that Council may, by vote, add to Authors with or without Author approval.

(Which is a fine process to document, but I don't think it's what xep1 says)

which _seems_ sensible, no? regardless of whats in xep1

Yes, I'd suggest updating xep1 to match actual process, rather than the reverse.

Right, and I'm absolutely happy to document that in XEP-0001.

and de facto council has always tried to reach out to the authors

Kev, You might have noticed I've said I'll do this kind of fixing-XEP1 thing in my Board candidacy page. Wasn't expecting a clear-cut case of process drift in the first Council meeting, mind.

Has someone not been paying attention? :)

Well, I haven't, for a couple of years, no.

Here is my feeling on how we lived the rules (actually even through automatic issue tagging on GitHub): 1. One of the current authors need to approve for a change to be accepted. A change may include adding a new author, so as long as the old author can be reached this works 2. If no author is reachable (in reasonable time), Council adds a new author. The second is not codified anywhere and the first is if any implied. We do the second, because council can specify a document shepherd, which is largely the same as a XEP author just that this is supposed to only happen at the time of a last call ✏

But I was aware that we have, like any org, process drift, and I'd much rather document what we do than try the reverse.

larma, That's my understanding of de-facto process. I'll try to get a PR against XEP-0001 together bringin de-jure into line with that for Board to review.