00:39 <whot> karolherbst: i don't know how to tweak the spam detection. it doesn't delete users, it either discards things altogether or they end up in the spam log as "not sure but it's probably spam", then we can tweak it from there by confirming ham or spam. bentiss may know of other toggles.

00:39 <whot> karolherbst: user deletion is manual, at least for "active" users, users who just create an account and do nothing get wiped after some time

00:40 <whot> karolherbst:even if you tag something as spam the user only gets blocked, we delete it manually afterwards (though I think there's a cronjob for that too to delete after some weeks)

09:02 <karolherbst> whot: okay, thanks for the clarification on the delete thing

09:04 <karolherbst> whot: right... tweaking the spam detection manually sounds like more work than just dealing with spam once a wave is upon us (enabling detection for a short while or something).... so I think it would be better _if_ we could tweak the detector directly with whatever is possible there... The only manual tweak which I'd say would be acceptable is to "wave spam detection for a user for all eternity and _never_ bother us about this user

09:04 <karolherbst> ever again"

09:04 <karolherbst> everything else is just pain

09:05 <karolherbst> if it only fixes it for like a week it's pointless

09:05 <whot> yeah, I agree, I just don't know if that setting exists

09:05 <karolherbst> yeah...

09:05 <karolherbst> would be good to know what options we have here

09:06 <karolherbst> but yeah.. I don't think "pinging admins to reenable spam detection" is a bad approach here. And it also doens't have to be done strictly by "formal" admins either

09:08 <whot> the problem is that none of the spam handling is exposed via API so it's difficult to write a bot

09:08 <karolherbst> ohh, sure, but e.g. there are also user reports

09:09 <karolherbst> but yeah...

09:12 <karolherbst> whot: anyway.. my thinking here is 1. users could ping admins on this channel 2. user reporting spam on gitlab is now going directly to the coc reoprting mailing list (because it's the same thing for abuse reports anyway), so if there are like a couple of spam reports in a short time, anybody from the coc team could also just hit the flip. The question is just, how long wouldn't we notice and how big of a problem would that be.

09:12 <karolherbst> but yeah.. I kinda prefer tweaking the spam detector itself if possible

09:13 <karolherbst> but I do think we have also other options

09:15 <whot> bentiss has this idea for damspam: https://gitlab.freedesktop.org/freedesktop/damspam/-/issues/9, basically - trusted user sets the emoji on a comment, that comment is removed as spam. same as we alread do with the Spam label but for comments rather than issues

09:15 <karolherbst> yeah, that would also help

09:15 <whot> i dont' recall the frequency but the worldcup stream spam was ... a lot. page after page of stream spam in the spam logs, and that was the stuff that *didn't* get through

09:16 <whot> been mostly quiet since though, so either akismet get a lot better or they are now into juicier targets

09:16 <karolherbst> yeah...

09:17 <karolherbst> in the end we'll have to choose which trade off we are willing to take, and I personally lean towards "remove pain from the user side"

09:17 <whot> but it's an arms race, if we get the emoji handling in that'd be quite good. then we could disable askimet for a bit and see how bad it gets

09:17 <whot> worst case it needs to be enabled again, ideally with crowdsourcing of tagging as spam rather than me/bentiss going through...

09:17 <karolherbst> yeah...

09:18 <karolherbst> I don't think "enable on demand" would be such a terrible idea... maybe damspam could even do it? or rather ping gitlab admin to enable it or something

09:18 <karolherbst> but uhhh...

09:18 <karolherbst> it's also fragile

09:20 <whot> damspam only works because it uses the API, pretty sure enabling/disabling spam is not available in the API

09:20 <karolherbst> yeah, fair enough

09:20 <whot> seems like a core setting you don't quite want to expose to bots :)

09:20 <karolherbst> heh

09:20 <karolherbst> :D

09:26 <karolherbst> whot: speaking of spam detection.. I think we have to update the privacy policy

09:27 <karolherbst> `We do not actively share information with third parties` is that even true anymore on gitlab?

09:34 <airlied> karolherbst: what 3rd parties?

09:35 <karolherbst> akismet

09:36 <karolherbst> and given they "use AI" there might also be moral implications

09:36 <karolherbst> like using comments on gitlab for training their spam detection and stuff

09:37 <karolherbst> and now that I know they use AI and user comments to train their models, I'm even less convinced we should keep using it

09:38 <karolherbst> or at least, we should state that this is what's happening

09:39 <karolherbst> and if we roll out a new privacy policy (because I'm sure that's reason enough to update it), how would we have to do it anyway?

09:41 <karolherbst> sure it's all public data (most of it), but.... still

10:24 <whot> karolherbst: huh, yeah, probably. that could get interesting since drafting a new policy would require lawyers, ideally one without armchairs attached

12:40 <daniels> whot: I’m not sure it would require lawyers. I mean, I just wrote the existing one …

18:33 <karolherbst> I mean.. if we are fine with that, that would also work...