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)

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)

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)