Aplucas0703

• Aplucas0703 (talk · contributions (views) · deleted user contributions · deleted uploads · recent activity (talk · project · deletion requests) · logs · block log · global contribs · CentralAuth) (search username in archives) (assign permissions)
• Reason: I've been working on wikimedia Commons (with occasional breaks) for a long while, including nominating pages for deletion and uploading files from Flickr. I have been a patroller and used that right, but honestly, being an image reviewer is more of the kind of thing I would enjoy doing. I have a good understanding of the licenses used on Commons, Flickrwashing, and some other common issues, including the FoP issues when inspecting certain files.--Aplucas0703 (talk) 02:36, 8 July 2026 (UTC)
• Scheduled to end: 02:36, 10 July 2026 (UTC) (the earliest)

Comments

FbrGBot (talk · contribs)

Operator: FbrG (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Find all images in the Category:Photographs by Willy Pragher and subcategories that are not categorized in Category:Photographs by Willy Pragher by year and subcategories. For all such files, check the date in the image description and - if possible - extract the year YYYY. Then add the file to the Category Category: YYYY photographs by Willy Pragher. Automatic or manually assisted: The bot performs its task automatically Edit type (e.g. Continuous, daily, one time run): Continuously (until no more aligible files are found Maximum edit rate (e.g. edits per minute): 20 Bot flag requested: (Y/N): Y Programming language(s): python using pywikibot FbrGBot (talk) 22:25, 10 July 2026 (UTC)

Discussion

Please do not edit manually with a bot account. How many edits do you expect in total for this task? --Krd 05:34, 18 July 2026 (UTC)

I understand. I'm expecting to edit ~150.000 files. FbrG (talk) 16:18, 20 July 2026 (UTC)

Plánovací kalendář BOT (talk · contribs)

Operator: Plánovací kalendář (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Three batch tasks, run from PAWS with Pywikibot, mainly on Wikimedia Czech Republic category trees (campaigns, photo contests, edit-a-thons, GLAM, programs) and related Czech topical categories such as streets in Czech municipalities:

1. Category maintenance: creating, editing, moving and merging categories; converting hard category redirects to soft {{Category redirect}}; adding {{Wikidata Infobox}}; adding by-year and maintenance categories (e.g. diffusing files into "YYYY in Orlová" by year of creation and creating the missing yearly categories via a local template). The bot only adds categories (it does not strip existing parents) and derives the year from the file name, falling back to the Information date field, skipping upload dates and ambiguous cases.
2. Linking Commons categories to Wikidata: creating Wikidata items for WMCZ campaign editions, photo-contest editions and edit-a-thons; adding the commonswiki sitelink and the relevant statements (instance of, country, organizer, point in time, follows / followed by, part of, logo, representative image P18), and correcting incorrect statements where needed.
3. Structured data on Commons (SDC): setting the creator statement (P170) on the operator's own files only, to the operator's own Wikidata item (d:Q99692082). The bot acts only on files whose Information author field matches the operator's own known signatures, so it never converts or assigns authorship of third parties. (Note: these edits are currently disallowed by Special:AbuseFilter/265 for non-autopatrolled accounts, hence the autopatrol request below.)

Automatic or manually assisted: Manually assisted, supervised. Every batch is first run as a dry run, reviewed, then run live with the output monitored. Tasks are idempotent. Edit type (e.g. Continuous, daily, one time run): Batch runs, repeated as needed (typically after WMCZ campaigns and events). Not continuous. Maximum edit rate (e.g. edits per minute): Up to about 6 per minute, usually slower, never faster than one edit per 5 seconds, and slower during peak hours.

Bot flag requested: (Y/N): Yes. Also requesting autopatrol, because some SDC edits (task 3) are disallowed by Special:AbuseFilter/265 for non-autopatrolled accounts. Programming language(s): Python (Pywikibot), run from PAWS. Test run:

• Task 1 (category maintenance):
  • By-year diffusion, creating the yearly category via the local template:
  • By-year diffusion, adding the year category to a file:
  • Sort key on a national street-name category: ,
  • Adding {{Wikidata Infobox}}
• Task 2 (Wikidata linking, edits on Wikidata)
• Task 3 (structured data): (currently blocked by Special:AbuseFilter/265 for non-autopatrolled accounts; will be added once autopatrol is granted)

Plánovací kalendář (talk) 21:04, 23 June 2026 (UTC)

Discussion

Please use edit summaries similar to Help:Gadget-HotCat when adding categories. I don't think that Wikidata item for task 3 is confirming Wikidata notability requirement. There are other ways to add attribution to Structured Data. EugeneZelenko (talk) 15:15, 24 June 2026 (UTC)

On the edit summaries: agreed, I will switch the category edits to HotCat-style summaries (e.g. "+2015 in Orlová").

On task 3: thanks, that distinction is helpful. For files where the author is a User: link, the author-name-string approach you describe (already handled by an existing bot) makes sense, and I do not intend to duplicate that. My task targets the gap: files where the author is given via the {{Creator}} template. There the Creator template is already tied to a Wikidata item, so the natural P170 value is that same linked item rather than a string. In my own case that is d:Q99692082, which meets notability criterion 1 (Commons sitelink to Category:Tadeáš Bednarz), and I would set it only on my own uploads, never for third parties.

Does using the item that the Creator template already points to, as P170, seem reasonable to you for the Creator-template case? Plánovací kalendář (talk) 17:21, 24 June 2026 (UTC)

I think both Wikidata item and {{Creator}} should be used for persons who are notable in Wikidata, Wikipedia, Wikisource, etc. terms, not for contributors of these projects. EugeneZelenko (talk) 15:21, 25 June 2026 (UTC)

Please summarize. Have all raised issues been addressed? --Krd 05:38, 18 July 2026 (UTC)

BorkedBot (talk · contribs)

Operator: BrokenSegue (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

I'm proposing that this bot populate the structured data Wikimedia Commons content descriptor ( P14416) with the value Not Safe For Work according to Falconsai/nsfw_image_detection_26 (Q140257486) for all matching images on english wikipedia.

I'm a long time re-user of Wikipedia and Commons work and I have interacted with many other re-users. A major sticking point for them in re-using the content is reducing the risk of sharing NSFW images. Obviously nothing is going to be perfect as the very concept of NSFW (or other categories) is inherently nebulous and culturally dependent. But even a crude filtering mechanism would greatly help re-users. I often cannot even safely share a prototype without fear that I'll bomb them with something.

I recently learned of Wikimedia Commons content descriptor ( P14416) and I think humans populating that would be incredibly useful and is the best long-term solution to this problem. However, I'm working on (and aware of other projects in progress) that would benefit from results sooner. So I propose that we automatically populate content descriptors for the most re-used content (leading images on Wikipedia articles).

This process may also help human annotators as they can look for images flagged by the AI and not yet reviewed by a human. I further propose the AI annotation be removed once a human has taken a look.

I've done some sample edits on the bot already for you to examine (though those were not selected from enwiki because I wanted a sample that had a very high NSFW rate). Obviously the content is NSFW.

Bot's tasks for which permission is being sought:

Automatic or manually assisted: Automatic

Edit type: one time run

Maximum edit rate (e.g. edits per minute): 10k / day

Bot flag requested: (Y/N): Y

Programming language(s): Python. Code on github

I'm a prolific bot operator on Wikidata (where my bot has made almost 4 million edits), a former Wikidata admin and a long-time enwiki admin. I've successfully deployed ML driven workflows there.

BrokenSegue 03:36, 17 June 2026 (UTC)

Discussion

I do support the proposal in general, however, I'm not a Fan of the very granular Not Safe For Work according to Falconsai/nsfw_image_detection_26 (Q140257486). There should be very few in use, so filters to be implemented can use them adequately and easily. So, instead, I would suggest that the bot adds the same humans are expected to use like Sexualized nudity, erotica or ecchi (Q138829111) or any of the others mentioned as constraints of the property. The "Falconsai/nsfw_image_detection_26" part for me belongs into a quantifier (if at all), we usaually use determination method (Q88321276). --Schlurcher (talk) 16:46, 17 June 2026 (UTC)

so there are models that produce more fine grained classifications but they still won't perfectly align with the ontology we have created on commons. but a larger point is that I didn't want my effort to conflict with the human-driven effort. I know that work is already controversial and adding AI-powered classifications I think would make it more so. I suppose whatever extension/script they make could check the qualifier as you suggest, but that does seem like more work for them and possibly muddies the waters. would using "flagged as possibly sensitive by an AI" (or similar) work as the content descriptor (with a qualifier for the model) be acceptable to you? BrokenSegue 13:44, 18 June 2026 (UTC)

I'm not convinced that AI-powered classification need to separated, maybe other can comment on this topic here as well. If this should be done, I think the classifier should be broad (as you suggested), such that it can cover other and future models or bot requests as well. --Schlurcher (talk) 11:31, 22 June 2026 (UTC)

Could you create a gallery of around 1000 photos your bot would tag with the statement the bot would add to them? GPSLeo (talk) 15:11, 23 June 2026 (UTC)

I've produced a bunch of examples of the model output https://commons.wikimedia.org/w/index.php?title=Special:Search&fulltext=Search&search=User%3ABrokenSegue%2FNSFW&ns0=1&ns9=1&ns11=1&ns106=1

I can produce more if you want. Or more of a specific type of image. The majority of images are not NSFW and so just randomly sampling isn't interesting. BrokenSegue 15:47, 23 June 2026 (UTC)

The files you want to add a statement are all files with a score of zero or what threshold do you plan to use? In the test set at User:BrokenSegue/NSFW-Test there is not a single nude photo in the sample but many files with a score. I would like to see a set of 1000 photos where you would add the statement based on the model output to evaluate the amount of false positives. GPSLeo (talk) 17:23, 23 June 2026 (UTC)

ok. i will do that. i believe i set the threshold very high but i don't have it on me. BrokenSegue 19:31, 23 June 2026 (UTC)

ok here is a larger sample User:BrokenSegue/NSFW-Big. This took about an hour to generate. I understand you wanted 1000 positives but image downloads get throttled so I have to go quite slowly. I can do more if you want. BrokenSegue 00:25, 24 June 2026 (UTC)

Based on the false positives at User:BrokenSegue/NSFW-Test, most of the false positives seem to be text-heavy images such as newspaper scans. Adding a few hardcoded "this is not NSFW" categories to the bot's logic would likely reduce this issue. --Carnildo (talk) 21:08, 23 June 2026 (UTC)

sorry. that file is really unclear and hard to parse. I should probably stop linking to it. The only file in that set that would be classified as NSFW is File:Rachel Roxxx, James Deen on the set of eXXXtra 1.jpg. That was to demonstrate that the average image is not flagged at all. It's confusing because sorting by score doesn't properly sort it. BrokenSegue 00:06, 24 June 2026 (UTC)

Is there any community consensus that Commons files should be tagged regarding NSFW? --Krd 05:31, 18 July 2026 (UTC)

There was definitely some discussion regarding this at VP which reached a consensus if I remember correctly, but I don't remember how it was supposed to be implemented. Nakonana (talk) 08:46, 19 July 2026 (UTC)

Please provide the link to the discussion. Krd 16:33, 20 July 2026 (UTC)

@BrokenSegue, can you explain (like we're 5, if necessary) how the stated problem ("I often cannot even safely share a prototype without fear that I'll bomb them with something.") directly necessitates this proposed bot task (as opposed to other alternatives) while having as few side effects as possible? I don't want to seem like I don't care about your work, but I question whether it is sufficiently representative to justify a rather large value judgment being applied for the express purpose of signalling a form of disapproval. Although you acknowledged that cultural variation is possible, I don't get the impression that you have sufficiently guarded against the possibility of both gross and subtle biases existing in the model used to identify content. It's not just that some bias exists, it's that without visibility of the premises underlying the algorithm, we can't judge whether those are acceptable harms. TheFeds 07:48, 19 July 2026 (UTC)

I have familiarity and experience with a large number of projects that try to re-use wikipedia and commons work. Not being able to determine (even roughly) if the content is "safe" ends up being a blocker for many. Re-users end up simply not using our content because of this. I've seen it happen. It is literally impossible to sufficiently guard against biases. Cultural variations mean that there is no universally agreed upon labels for these kinds of content warnings. We should not let the perfect be the enemy of the good. My proposal allows for the possibility of multiple different models being used which can each have their own specific biases. Re-users relying on these open models can independently audit them to determine if the biases inherent in their training are acceptable for their use case. BrokenSegue 16:07, 20 July 2026 (UTC)

If possible please provde one or two actual examples. Krd 16:33, 20 July 2026 (UTC)

In addition to the examples, is a tag on Commons/Wikidata the place for that metadata? Wouldn't that imply that you could create the tag representing this model's output, and I could pick some other arbitrary model and tag it with its output, and every ideologue could tag it with what they claim is their model's output? I can completely get behind a reuser wanting to rate content according to their chosen criteria, but what is stopping them from doing that analysis and maintaining the metadata on their own infrastructure? Does their system design depend on Commons/Wikidata providing not just content, but moderation functions? If there is a reason it needs to be on Commons/Wikidata, would a userspace/Toolforge implementation be adequate? TheFeds 22:36, 20 July 2026 (UTC)

two examples of projects that ran into this problem? I mean the project mw:Readers/Reader_Growth/Image_Browsing ran into these exact issues. (Note that while I work for the WMF this is not related to my work). Google includes images from commons at that top of their data previews that they have to filter for NSFW. I'm working on a project right now that shows users Wikipedia articles and images and I would prefer not to show them shocking images. Basically any project that is going to display images from Wikipedia articles to children (so most educational contexts) is going to run into this. There are laws governing these kinds of things.

Imagine you are any organization (maybe a news org) and someone says "lets enrich this content with related Wikipedia article content". The next problem is going to be "ok but we can't show explicit images" on CNN/IMDb/etc.

We don't need to allow any arbitrary model to be added. We can select a few via the bot review process. Putting the data here is the most convenient. It allows reusers to filter using the same APIs they are already using. Yes, I could put it somewhere else. Putting it here though makes it visible and I think allowing humans to reject/refine the model's output would be useful. If/when human labeling of images is at strong coverage maybe we can stop this process.

I would also respond "Why not put it here?" Structured data is underused as it is. Are any widely used applications using structured data? This feels like an strong use-case. BrokenSegue 14:58, 22 July 2026 (UTC)

Accepting your premises for a moment, how could the bot review process be expected to detect a hypothetical content filtering method that declares glamour photos of people of a certain race "NSFW" at a 5% higher rate? (I said race because it is convenient to discuss, while recognizing that it is not convenient to define.) We own the result, even if we don't realize it's happening. With a conventional algorithmic approach, despite the tiny visibility of the bot review process, and fact that there is no guarantee of expertise (especially in content), there is generally a well defined problem statement, a decent chance that someone can review the code, and a weak expectation that high fidelity results flow naturally from the reviewable structure of the code. Even that much isn't really practical with LLM weights.

If we had an algorithm for detecting pictorial depictions of Muhammad (a heresy by some accounts), would this be the place to put it? If we had multiple algorithms for Muhammad-detection, would we have a data field for each of them? Would the bot review process have to choose between them? Or allow all of them while owning the idea that hosting tags based on ideology is fundamentally going to make someone unhappy. If that's allowed, would we host results of an algorithm tagging offensive depictions of Jews, and then have to consider the implications of people upset by the images, and people wishing to perpetuate the images, each wishing to control the discourse?

I'm really not seeing how this NSFW problem statement is generalizable, given that there is no recognized authority or consensus for what that means. It emerged from Internet culture of the late 1990s and 2000s, with the cultural expectations of U.S. middle-class office workers dominating. It is telling that the Googles of the world do not attempt to use loaded terms like this, even while they attempt to cater to the whims of people who desire such things—in other words, they take a side (which could even be the right side), but have plausible deniability that they are not implementing anything in particular. TheFeds 20:06, 22 July 2026 (UTC)

any potential re-user of commons content will run into exactly these issues you describe. and they will decide to not re-use commons content rather than deal with them. if the goal is to make commons data useful for the general public we would want to do this work for them.

yes, there could be bias. there probably is! performing this bias audit is beyond the time/resources we have. we aren't endorsing any particular use of this model's output. do you think a re-user who did decide to do this themselves is going to look for bias?

what we are deciding between here is less re-use of wikimedia content or more use with a small possible introduced bias. if/when bias is found humans can repair it. wikimedians are too comfortable saying "no" to everything, not realizing that they are slowly cutting off the project's relevancy.

i cannot imagine how this proposal does harm. i'd be happy to just use the existing human labeled P14416 images but there's not many and there doesn't seem to be actual progress. the day that isn't true we can delete these. I also argue the existence of this data would speed up the human labeling. BrokenSegue 02:33, 23 July 2026 (UTC)

As already raised above, such general discussion shouldn't be held is this backroom but on the village pump to involve the whole community. As far as I'm concerned as a buraucrat, this bot request cannot be approved without further community discussion. Krd 05:03, 23 July 2026 (UTC)

FlickrResourcesBot (talk · contribs)

Operator: DaxServer (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information) (assign permissions)

Bot's tasks for which permission is being sought: Add {{Flickrreview}} template to files under Category:Uploads using Flickypedia so that the bot can add improve SDC (task 1) for those that pass review

Automatic or manually assisted: automatic

Edit type (e.g. Continuous, daily, one time run): Continuous

Maximum edit rate (e.g. edits per minute): 6

Bot flag requested: (Y/N): N

Programming language(s): Python, review integration at https://github.com/DaxServer/wikibots/pull/88

-- DaxServer (talk) 18:55, 16 April 2026 (UTC)

Discussion

• Here's a test run: -- DaxServer (talk) 18:55, 16 April 2026 (UTC)

they dont need review. RoyZuo (talk) 19:17, 16 April 2026 (UTC)

If they did, does it make sense to tag them for review instead of reviewing them right away? --Krd 05:54, 9 May 2026 (UTC)

@DaxServer:  ? --Krd 13:32, 16 May 2026 (UTC)

Hey @Krd Let me ask in COM:VP/C about this, I think that would be a better forum. Sorry for the delay, have too many things at my hand atm it seems. -- DaxServer (talk) 13:54, 16 May 2026 (UTC)

I've posted it on VP/C - Commons:Village pump/Copyright#Should Flickypedia uploads from Flickr be tagged for license review? -- DaxServer (talk) 13:00, 5 June 2026 (UTC)

Please summarize the result. Krd 05:00, 27 June 2026 (UTC)

@DaxServer:  ? --Krd 04:40, 16 July 2026 (UTC)