XSF Discussion - 2022-01-25

jonas’ / emus: it is possible to block individuals from contributing to your organization's account, on Github, through the organization's account settings (under "moderation settings").

There's no need to involve Github's support team for that, we can do that ourselves (and do not need to provide a reason in the UI, when adding the user to the block list).

MattJ:

I dont know but slightly giving my +1

Guus, yeah, figured that out later

It is wild to add an existing XSF member to a blocklist of our own tooling though. I'm not sure if we have a process for this.

we probably don't

Is it a board or iteam matter?

Is answering that a board or iteam or member meeting matter?

(how many levels of meta can we go?)

and that's why you need CoCs lol

To be clear: I'm not advocating to add Neustradamus to this list, at least not without further deliberation and possibly a(nother) warning. My intent here was to point out that there are options available other than the tooling suggested so far.

I'm not unfamiliar with Github's blocking functionality, and have (unsurprisingly) had cause to use it before. However not within the 'xsf' organization. I'm not going to make that decision on my own, especially against someone elected a member by the other members.

Well, maybe we should keep it with a clear last warning first.

as someone who has them blocked on my own github orgs as well as on xmpp I agree that we probably shouldn’t just block elected members from the github org

as much as i personally would welcome that action

Yah, probably best to take this up at the membership level if any action is to be taken. Though it's unclear to me whether they've actually violated the CoC or if they're just kind of annoying and not really a problem (unless they reached out claiming to represent the XSF or something more serious)

Indeed

I don't think its a violation of the CoC as written

FWIW, I think if they're pinging people causing annoyance to XMPP devs (or non-XMPP devs) who're mostly outside the community and making the XSF look bad, something should be done.

What bugs me is that I'm convinced that their actions stem from good intentions, which makes things a lot less clear-cut for me.

"The road to hell is paved with good intentions"?

that's different.

Is it?

I've always interpreted that as "having good intentions but not following through with them"

Oh. That's not how I've used it.

so if that's the interpretation, then I think it's different. I might be wrong in my interpretation though.

I've always used it as "having good intentions but the result not being positive"

my interpretation is, people have good intentions and cause harm with those

harhg. I feel a rabbit hole to tumble in coming up...

Wikipedia lists Guus's as an alternative interpretation. So we can all be right.

well, in that case, it is veyr appropriate :)

aaanyway.

> Guus escribió: > harhg. I feel a rabbit hole to tumble in coming up... No worries, Im with you ✏

Lets not overkill this. I apologized to the external parties (to the ones I saw and to my best understanding). And they were fine (thunderbird) I think a clear warning and possible actions what happens is this continues be stated. Maybe also asking to not use @mentions within our repos anymore. ✏

s/use/abuse/

Lets not overkill this. I apologized to the external parties (to the ones I saw and to my best understanding). And the dev was fine (thunderbird) I think a clear warning and possible actions what happens is this continues be stated. Maybe also asking to not use @mentions within our repos anymore. ✏

okay

emus: Sounds sane to me.

k

All I meant by 'something should be done' is 'this sholudn't be ignored'.

Yep, I would say so too. but lets keep this not too formal and someone can reach out. I can do so if you tell me what points you want me to make finally

we shouldnt waste more energy with this too I think

I think simply 1) Don't open refresh PRs unless it's your project 2) Don't ping people

Any other points? Would you be okay with this? MattJ Guus jonas’

We ping people about that all the time

Someone just pinged Daniel about it here

yes. but not entire teams and in bulk requests ✏

Right

I think was me before seeing where it goes ✏

And the MoonguseIM and Thunderbird where pinging of "random" devs

and @mozilla

Sorry, I don't have much bandwidth for this right now. Seems sane, but "don't ping people" is pretty broad. I accept that codifying acceptable social behaviour is a difficult task :)

What's left to do in order to move to basing that on DOAP instead?

Zash: +1

And like, just list inactive projects at the bottom in a boring simple list of shame

Yes doesn't the new awesome thing that uses doap fix this? Can we smash that merge button now?

MattJ: so you dont prefer that I can reach out

To my mind, a polite request not to ping people for this one individual as they don't seem able to determine when it's appropriate themselves, is reasonable.

Zash, indeed. The annual renewal thing was always a hack I wasn't keen on, and it has always had loopholes like this. Let's just move forward with DOAP (or anything else).

> moparisthebest escribió: > Yes doesn't the new awesome thing that uses doap fix this? Can we smash that merge button now? not yet, awaiting some more works (link mauve maybe you find some time)

(do we need a board decision on that?)

Please no

> Kev escribió: > To my mind, a polite request not to ping people for this one individual as they don't seem able to determine when it's appropriate themselves, is reasonable. +1

The website is commteam's, it's just a simple software listing, how hard can it be? :)

> how hard can it be? famous last words, before descending into madness

> MattJ escribió: > The website is commteam's, it's just a simple software listing, how hard can it be? :) ...

that Software listing PR is missing the DOAP processing part developed by Link Mauve

thanks for clarifying

Save us Link Mauve, you're our only hope!

Ok, but then I will write a personal message, ok?

emus, go for it

emus: as an aside I like how your client leaks your language setting when you quote people :)

> Zash, indeed. The annual renewal thing was always a hack I wasn't keen on, and it has always had loopholes like this. Let's just move forward with DOAP (or anything else). How DOAP should help here? AFAIR it mostly list software capabilites?

(i.e. determining active/inactive)

I guess only active projects provide a DOAP file at all

active/inactive has probably always been a poor shorthand for 'good'

Wojtek, technically this was never about active/inactive

Lets you get compliance level

Technically this was about finding a way people were happy with of removing Pidgin from the listings. ✏

We just wanted a way to sort the clients that was easy, so we can show the better (~more up-to-date) ones first

> Technically this was about finding a way people were happy with of removing Pidgin from the listings. lol :-)

if I remember right the motivation for the "renew every X" was to keep pidgin away, that failed, how about we just stop doing it ? ✏

well, I do understand with the sentiment to somehow filter outdated software (that doesn't support modern features which gives bad impression of XMPP) but bumping "last updated" doesn't quite achieve that (as stated above)

> Lets you get compliance level understood, thanks!

As said, not great, but nobody had any better idea at the time

Yes, I think so too Zash I think we all agree to continue with Doap file for many reasons. How we extract and evaluate data and turn it into an overview is another thing and we will find a at least better solution

moparisthebest: yes, I dont care at the moment. but I thinl there is an open issue already

I would prefer to keep all clients and let the developer update a "last release date". I think XMPP should be independent of "modern" clients. It should be another place to define those clients.

What users see: "XSF recommends Pidgin"

Last release date has obvious issues, particularly around things like Pidgin. I'm not sure there's a particularly good solution really.

Stefan, DOAP would certainly help users in making an informed decision. I'm not saying this concept (clients advertising support by themselves) is perfect, but it sure is better than the list there is right now

DOAP can include release dates fwiw

let's tackle the "clients lie in DOAP files" problem when it comes up

Link Mauve to the rescue

Yes, that would be really great

I wrote a message to Neustraddamus

Hello everyone, the website is almost ready and the promo files are waiting to be merged (I dont wanna paste the files here again). If you know a university or good place where to promote please go ahead: https://xmpp.org/community/gsoc-2022/

If you have a project that is good to participate please take a look at the wiki

i saw LastActivity deprecated

i just wanted to say its the only way to get server uptime, and i think thats a nice thing the XEP provides

oh wait ignore me, that was last activity in presence

yeah we dont need that

https://datatracker.ietf.org/doc/rfc8553/ İs this latest ietf XMPP core update?

Latest XMPP core is RFC 6120 (XMPP IM is RFC 6121)

> MattJ wrote: > Latest XMPP core is RFC 6120 (XMPP IM is RFC 6121) Okay thanks

I missed

MattJ, on that matter :) there is a missing server direction for /rfcs

I hereby invite you to create an issue at https://github.com/xsf/infrastructure/issues with details and... ping me

I've got a lot going on, but either someone can take care of it or I'll look at it next week

Take your time Matt