XSF Discussion - 2020-08-20

Anyone else around?

ralphm, Guus, Seve?

oh, sorry

yeah

it's one of those days

If everyone's on holiday I'm going to feel like I'm missing out

😁

🦗

Ok, I'll assume unicode boxes mean let's go

0) Roll call

it was a cricket 🙂

but yeah

:)

ROLL!

:D

(sorry)

:)

Oh yeah, I added something

1) Topics for decisions

1.1) Sponsor Secure Messaging Summit?

Context: https://claucece.github.io/Secure-Messaging-Summit/ (I think you've both seen already, since it was shared in commteam)

I've briefly glanced over it, not expecting it to pop up for discussion here

(dind't review trello before the meeting - a pre-sent agenda would be nice indeed)

One day :)

I in principle have no objections to sponsoring the event - it seems to align nicely with our objectives.

this all from a cursory look

"You can be another sponsor if you like! ;)" I can't find how or what it takes to become a sponsor

But yeah, the summit is not XMPP-specific, but obviously within our domain

(eg, the headlines make sense)

and yes, the sponsorship part is vague, but I saw it and thought it would be worth bringing up for discussion

so if we're not opposed, then I propose someone reaches out to them for more details

and if someone wants to volunteer for that, great, and I can otherwise ✏

I'd happily push this to anyone but me - neck-deep in post holiday madness

I think it would be nice to have XMPP/XSF around there, since it looks like there's nobody from the community participating there, so it is a way to have XMPP around

Do we need to bring up them using Zulip for chat?

I don't think so?

Might come across as weird for us to sponsor an event that's using different technologies than ours.

I don't particularly mind, as I'm primarily interested in the topic of the event, rather than technology used.

Zulip isn't federated (afaik) but it is open-source

I'm merely trying to anticipate raised brows from our own community.

Yeah, I don't see an issue but if someone has an objection then I'm happy to continue on that point

fair enough

Ok, so... I'll take that as no objections to reaching out. Any volunteers? If not I can.

That's a chance for some XMPP awareness, that's why I think it is good to see if it is doable for us to become sponsors

I would be happy if you can handle it MattJ, but I can help too if needed

Ok, great

Looking over the other items on the board...

Looks like we have a few stale items

2) Items for discussion

2.1) What to do with open PRs in xsf/xmpp.org

This was added by pep. but apparently raised by emus: > PRs are "pilling up" in the repository and there is nobody to look into them. Istr board and commteam have commit access (probably iteam as well). Should we put something in place to review things on a regular basis. Any other idea?

As I understand it, commteam are in charge of the website (content, anyway)

Does board _need_ to do anything here?

I was just about to say, I don't see why this is a board matter. Though commteam failing to do what we need does become a board matter

People that have permission to work on issues get email notifications of changes - I don't think it's a matter of people be unaware.

I do not get those if I'm not mentioned, maybe something I can look at

I'll try to handle take care of that item

Ok, thanks!

There are 12 PRs, I don't consider that a mountain, I've seen worse

if any team wants to put in some kind of mechanism for periodic reviewing things, by all means, go for it. I'm slightly worried that more procedure doesn't necessarily help, but we can always try.

to be fair, I think a bunch of them were worked on recently.

Yeah, nothing looks ancient

Ok, so Seve will look into it, but no other action required from Board here

and if it was ancient, then it was probably not important enough to have been resolved with any kind of priority.

Yes, don't worry, I'll make sure we handle what we need to handle here 👍

Thanks

Of the other cards on the board, I don't see any that I'm 1) comfortable with discussion without ralphm/pep. participating 2) aren't blocked on someone

so...

3) AOB

none from me

hmm

None here

when does our term end?

(do we need to start thinking about elections yet?

something to look into later, maybe. Just something that popped to mind

The last election date was 2019-11-21

so a while yet, but yes, something to start thinking about soon

4) Next meeting

Same time next week wfm

+1 ✏

+1

5) EOF

Thanks all

thanks!

Thank you! Also thanks for chairing MattJ, very appreciated :)

I'll send out minutes shortly

Done

Seve, MattJ: I mentioned the situation, which seem to be the case on the other repositories, too (no matter who is reponsible) we have issues open for years already. I furthermore didnt know that CommTeam is responsible for the website alone. Therefore I intended to start a discussion how to treat open issues/PRs and who can review those (meaning with background knowledge). Often people claim for example the client lists for example are not up-to-date, however there were 10 not merged update PRs. I think this is frustrating for contributors in general and it also does not help if noone feels responsible.

> if any team wants to put in some kind of mechanism for periodic reviewing things, by all means, go for it. I'm slightly worried that more procedure doesn't necessarily help, but we can always try. > to be fair, I think a bunch of them were worked on recently. I think that would be good in general

Of course one can subcribe to repository notficiations (Watch repo) ✏

FTR, I was subscribed to xmpp.org before I got my write access revoked when we cleaned up permissions and people figured out that I wasn’t in commteam :)

Of course one can subcribe to repository notficiations (Watch repo) ✏

🤔️ when was that?

was there any movement regarding message styling?

i think there was some issue with 394 because it does not specify how to count the characters?

lovetox, https://xmpp.org/extensions/xep-0426.html discusses that

ok was there any other drawback with 394 i should know about?

can we replace xhtml with it?

lovetox, at summit we discussed that it would be great if one can specify in 394 that a char/string is actually meant as a formatting char for clients not supporting 394 (i.e. clients doing only 393) and should not be displayed to users if the client supports the corresponding 394 markup tag. This would be useful so that e.g. lists don't end up with double bullet point as in the example https://xmpp.org/extensions/xep-0394.html#usecases-itemized but instead just une bullet point as one would expect