XSF Discussion - 2020-06-25

There is a solution about spam in MUC Rooms? Example in the Conversations MUC Room?

Neustradamus: yes, the solution is for the admin of the room to ban them

moparisthebest: another solution ah ah

Because it is not the first time

Now it is Gajim MUC Room!

or mod_firewall and have fun :x

(to do that automagically-ish)

I wonder if it's possible actually to do that in MUC with mod_firewall

When the cat's away the mice will play

Same problem with mailing lists, forums, IRC channels etc etc

yeah

If you have a solution though Neustradamus please share

Ejabberd MUC Room now!

Prosody MUC Room too!

it's 4:40am CEST, not sure many people care in these rooms :/

The point I was trying to make is I don't think there is a solution or someone would have already discovered it

You can slap a little rate limiting on and they'll just use multiple accounts or adjust speed

moparisthebest, they need to realize it first. then they'll come back with another solution indeed. as you're aware it's just a battle of resources

Yep, game of cat and mouse

We already have some controls in place in prosody@ (we've dealt with worse than this before now)

You may notice the number of spam messages in prosody@ is far fewer than e.g. conversations@ (where it highlighted each person)

0. Welcome

Who do we have today?

!

Also hi

o/

Sorry for not sending an agenda. Will do better next week.

save me.

I mean: hi.

If there isn't more board members joining I guess we can hear your opinion on the CLA thing ralphm if you have one, to add to last week's

Virtual hugs, Guus.

Opinion / wisdom, if you have hints as to why :p

(I have a full page of feedback written down. I'm at page 6 of a 33-page contract)

pep., sure

1. Minute taker

I'll take this.

Thanks

2. Contributor License Agreement on GitHub contributions.

I do agree (again) that we need these.

Like our XEP submission process explicitly mentions this, we similarly need to know what the position is of other contributions.

'position' ?

I know that there are opposing opinions on this topic (http://esr.ibiblio.org/?p=8287), that consider this to be mostly cargo culting, but I think they are fine for what we want them for.

I mean making it explicit what the license of the contibuted work is, and what entity holds the corresponding rights.

in that case: 'other' ?

(isn't the providing of the XEP the contribution?)

other than XEPs

We have CLA in place only for contributing of XEPs, afaik.

are you saying that we should have this in place for other contributions too?

I mean other than 'whole XEPs', i.e. the initial contribution.

Like subsequent modification of the XEP?

in any case, XEP-authoring-related contributions?

Thanks for the link, didn't know it. As an aside I'm generally against CLAs, but it's just because I'm happy to deal with the consequences of having to contact people or rewrite code to change the license of a project (and that's the extent of my understanding of the legal stuff). (That also doesn't mean I'm opposing the CLA here)

I haven't really considered other contributions, but maybe.

Guus: yes, subsequent contributions.

Ok, that's how I understand the current CLA. Sorry for the noise.

Guus, "We have CLA in place only for contributing of XEPs, afaik." tbh this part wasn't entirely clear to me

The xeps repo does contain a license file with the IPR policy in it

pep. I ment to say that we currently do not ask for a CLA when you, for example, submit a PR to change our website

Ah for the website no, but say the .. xep template

(and I was wondering if that was something that ralphm was referring to, which we now have established he was not)

That xslt transformation etc.

let's circle back to that if we need to

but focus on the XEP stuff first, as that is what we already have in place.

Right.

I don't think there's anything to change at this point.

Regarding the rest of our repos, website, there's an open discussion item that we should pick up (not today)

This topic partly stems from a (mostly technical) desire to change _how_ we record the CLA.

this ^

I'm ok with a procedure like mentioned in Q2 in the trello item.

But for now, if you do not want to do the clabot thing, you can send an e-mail.

Oh, and I don't think the downside of retracting consent isn't there. I don't think you can do this retroactively, and if you no longer want to abide by the IPR, you can stop contributing.

What do you mean? It's not possible to retract consent?

You either contribute according the IPR, or we don't accept the contribution.

You can't contribute according the IPR, and then later say: oops, haha.

Can we conclude that a) CLAs for XEP contributions remain to be signed, and b) there's no need to immediately restore clabots functionality, if the editoring process moves away from GitHub - as long as the CLAs are supplied via the email route?

I think so

jonas’ does that sufficiently resolve your issues?

does that / would that

I'm happy to receive that answer asynchronously. Have to go into another meeting in a few minutes, so can't go over time.

(he's probably not here)

.

(he probably is)

thanks, good enough info for me

Do we need to motion this?

It effectively isn't much of a change of the current policy? ✏

I don't think so

So moving on

3. AOB

None here

Nada

Nope

4. Date of Next

+1W

5. Close

wfm

Thanks people!

Thanks

Thank you very much everyone

Guus, having the current policy reconfirmed is what I was after, so thanks for that