XSF Discussion - 2018-07-09

Hello!

Hi!

Ohai!

There is an interesting question here... What to do with MUC participant list, when client leaves the room because of connection error? Is it a good idea to cleanup the list, or maybe leave them all, but display offline, or maybe keep the list in it's last state before we disconnected?

Yagiza, I clear it

Psi displays last state, Vacuum-IM and eyeCU cleans up.

Did any1 ever discussed it?

Or every1 just do as he likes.

"any1"?

Conversations always displays the full member list in members only rooms. So offline members are shown as such

Anyone

But I don't think you should display everyone who has ever joined a muc as offline in that list

Especially since you can't identify if someone rejoined with a different nick

Yes. We are choosing between "keep displaying last state" or "clear list".

daniel, I think you have the same misunderstanding as I originally did: Yagiza is asking about displaying the participants in the local client when the local client is disconnected

Oh

Yeah!

In theory, you should be able to store pending outgoing PMs to other participants when offline, allowing the user to type... Of course you can not be sure if they will be there when you return, but there are the same reace conditions while being online.

So... removing one word from a XEP that leads to people misinterpreting it

Is that an editorial change I can just make a PR for? Does it need a revision bump?

What was the word?

"initial"

In the context of the response, the words "initial query" are used to refer to "the query at the start of the results"

But it easily leads to the interpretation (which is already difficult enough to avoid) that there is such a thing as an "initial query" and a "page query"

Sounds editorial to me

MattJ, is this about RSM?

in any case: make a PR with the change, I’ll add the revision block if I think it’s needed (and I may -- since it changes the interpretation many people seem to have initially (pun not intended), it makes sense to have a revision block for that so people can clear up their confusion using the attic)

It's about MAM

> Is that an editorial change I can just make a PR for? Does it need a revision bump? All changes need a revision bump, whether editorial or not, just a question of which version part gets bumped.

reminds me to update the atitc

Kev, pretty sure grammar fixes and typos haven't had revision bumps in the past

They might not have, but they should.

We agreed a few years ago that all changes would have version bumps from then on, and that particular versions would be immutable.

Alright

I’m pretty sure I haven’t version bumped some very trivial typo changes

(and not updated the attic, either)

(so it’s at least immutable)

(once the next version has been released, it’ll be as if the typo fix was in that next version)

actually, I think this isn’t the worst way to do things.

In this case, if we're talking about a change that makes the XEP less confusing, that means we're changing the perceived meaning and bumping seems particularly important.

Kev, I agree

I would definitely revision bump that as I explained above.

Properly trivial typos I can go either way on.

but it feels awfully overheaddy to me to version bump a "fobar" -> "foobar" typo fix

When there's a process I think it's good to follow it, but ... as you say.