[01:00:39] https://wikitech.wikimedia.org/wiki/Technical_debt/Unused_config updated for 2022 :) [12:15:44] I'm from the small volunteer team that develop the Commons app for Android. Google recently started to require us to "moderate" objectionable images that the app shows to users. Has anyone here deal with this issue? [12:15:59] Especially, I wonder what the Wikipedia app does about this. I believe they have a Suggested Edit feature that shows images. [12:17:42] whym: i believe there's a page with images to filter out on [12:17:49] i am trying to find it's name [12:20:39] enwiki has a bad images list [12:20:47] but that doesn't exist on commons [12:21:12] RhinosF1: hmm, do you have a link to the enwiki list? [12:21:26] whym: https://en.wikipedia.org/wiki/MediaWiki:Bad_image_list [12:21:59] note: do not click the images on that list unless you want explicit stuff [12:22:16] RhinosF1: tx a lot! [12:22:53] whym: no problem, i'm not sure why yet it doesn't exist on commons [12:29:19] RhinosF1: at least a few images on the enwiki list are actually hosted on Commons, so the list might anyway help for our purpose [12:29:37] potentially [12:30:39] whym: it might be worth reviewing words commonly in some of them titles and excluding any image matching a pattern too [12:32:27] Offensive images tend to have specific categories on Commons (like "human genital of XYZ"), so banning by categories would be another thing we could do [12:34:43] yes that's a good way [12:34:57] i think categories or structured data is probably best [12:35:10] rather than a manually maintained list [12:40:55] structured data would be great, although we will probably have to start by collecting such data [12:41:40] I need to go, but we look for advices and suggestions at https://github.com/commons-app/apps-android-commons/issues/5024 [14:45:13] shameless plug, my good buddy Carl George is doing a talk on RPM packaging tomorrow at 1830 UTC: https://fedoraproject.org/wiki/Nest_with_Fedora_2022_Schedule# [22:17:23] https://www.theregister.com/2022/08/04/gitlab_data_retention_policy/ "GitLab plans to automatically delete projects if they've been inactive for a year and are owned by users of its free tier." [22:17:33] Funnn [22:17:52] probably need to make list of upstreams we depend on that are on gitlab.com :| [22:18:19] > A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive. [22:18:29] or just make a bot that comments on an issue once a year [22:19:29] the bot needs to be hosted on gitlab and keep itself alive as well [22:26:14] all those mw extensions that people think will be fun then start to rot after a couple of months [22:42:21] legoktm: I have a strong feeling that they are going to reverse that decision. If they actually cary it out they are basically telling all FOSS projects that their services are not trustworthy. It will undo all the gains they got when Micro$oft bought github and a mass of projects migrated to gitlab in protest. [22:42:54] but... maybe they really don't get it and will shoot their own foot [22:43:09] * bawolff enjoys bd808's optimisim [22:43:26] that all seems so obvious to me, so then why would they even try to pursue this policy in the first place? [22:43:52] but yeah, if they don't reverse they will definitely just be the next sourceforge [22:45:24] my guess is someone in a non-technical function looking at "daily active user" type stats dreamed up the purge idea [22:45:58] yeah this feels like the sort of the press release that causes someone to run into a manager's office saying "What do you think you're doing" [22:46:04] I mean, sf.net still hosts a read-only version of our very old CVS! https://sourceforge.net/p/wikipedia/code/ [22:47:05] github: "we will put your code in the Arctic permafrost so it is never lost" gitlab: "we will delete your code if you stop touching it" [22:47:41] bawolff: I have many less optimistic feelings about gitlab's open-core business model, especially after working gitlab API integration code this week. ;) [22:48:15] heh, I forgot about the arctic vault thing. yeah, that makes it look even worse [22:48:41] I know M$ is evil (was evil? Guess its not the 90s) but honestly, they seem to be doing a good job with github [22:48:56] I'm going with "less evil" [22:49:12] "about on par with google"? ;) [22:51:37] Nah, google bribes us with GSOC to look the other way. I don't see any bribes coming from MS [22:52:37] the bribes come from Bill Gates directly [22:54:24] any yet every year there is a debate inside GOOG about killing GSoC.... [22:55:48] I'm pretty sure I've seen volunteers spend more time and energy just on YouTube video imports than the cumulative impact of GSoC on the movement would justify. [22:56:39] * bd808 is salty today and should go find other things to do [22:57:20] we should have a GSoC student work on YT video imports [22:57:31] bd808: The darkside beckons to you [23:00:41] but we also got some really good contributors out of GSoC and GCI like Yuvi, t.aavi, etc. [23:01:10] legoktm: I'm not sure about that bawolff guy though [23:01:23] ikr, so shady [23:01:52] was your GSoC project your intro to MW development? [23:02:11] your name doesn't end in "vi" so it really would've broken the pattern [23:02:15] no, i was here a bit before that. But it was definitely near the beginning [23:02:41] https://www.mediawiki.org/wiki/Outreach_programs/Success_stories has a bunch of folks listed, but not all of them for sure. [23:02:55] why is Yuvi not in that list... [23:03:14] we should put slaport on there too [23:04:10] wow, that list is way longer than I expected [23:04:12] * bawolff did not know that both Moriel and Niharika were gsoc/outreachy [23:04:16] that's really awesome [23:04:49] we started that list at a tech managers offsite where Victoria was asking why we participated in GSoC :) [23:07:09] MatmaRex and ashley were GSoC students too [23:09:15] I think we could probably also call mdale and Jeroen De Dauw successes (No idea how much they participated before gsoc) [23:09:32] * MatmaRex reads back [23:19:43] if only there was a way for folks to add content to a wiki... [23:21:02] good job that anyone can't edit it [23:21:06] who knows what would hapen [23:21:34] Personally, that sounds like a security risk to me