Commons:Bots/Requests

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
This project page in other languages:

Shortcut: COM:BRFA

If you want to run a bot on Commons, you must get permission first. To do so, file a request following the instructions below.

Please read Commons:Bots before making a request for bot permission.

Requests made on this page are automatically transcluded in Commons:Requests and votes for wider comment.

Requests for permission to run a bot

[edit]

Before making a bot request, please read the new version of the Commons:Bots page. Read Commons:Bots#Information on bots and make sure you have added the required details to the bot's page. A good example can be found here.

When complete, pages listed here should be archived to Commons:Bots/Archive.

Any user may comment on the merits of the request to run a bot. Please give reasons, as that makes it easier for the closing bureaucrat. Read Commons:Bots before commenting.

Operator: Fl.schmitt (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information)

Bot's tasks for which permission is being sought: Add {{Information}} to Media missing infobox template. See exhaustive preparative discussion on Commons:Bots/Work_requests#Media_missing_infobox_template. The bot tries to put as much information as possible into SDC fields (author, source, captions, date), since {{Information}} uses those data as default.

Automatic or manually assisted: Manually assisted. The bot follows "divide and conquer" tactics. Since it seems to be impossible to apply one solutions to > 300,000 media files lacking an infobox template, it will work on sets of files, usually defined by same author / creator (assuming that those files share sufficient similarities). The bot will be run multiple times on that set of files in different modes. First, analyze the file page content and try to categorize each of its components, without modifying and content on Commons. This step will be repeated (manually) as often as needed to adapt the categorization patterns, until a pattern set that fits for all file pages of the current set has been found. Now, a "dry-run" ("simulation") generates an overview over the "planned" modifications (see txt and SQLite analysis and simulation results for Category:Media missing infobox template (maps t1)). Only if this simulation result seems acceptable, the bot will run in "doit" mode to apply the "proposed" edits.

Edit type (e.g. Continuous, daily, one time run): Multiple times a week, but not daily.

Maximum edit rate (e.g. edits per minute): Maybe 5-6 per Minute?

Bot flag requested: (Y/N): Y

Programming language(s): pywikibot

Fl.schmitt (talk) 21:56, 6 September 2024 (UTC)[reply]

Discussion

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

Bot's tasks for which permission is being sought: Commons:Batch uploading/U.S. Army Corps of Engineers Digital Visual Library

Automatic or manually assisted: Automatic

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

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

Bot flag requested: (Y/N): N (see #2)

Programming language(s): OpenRefine

-- DaxServer (talk) 20:58, 1 September 2024 (UTC)[reply]

Discussion

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

Bot's tasks for which permission is being sought: Simple text replacement

Automatic or manually assisted: Automatic manually assisted

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

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

Bot flag requested: (Y/N): Y

Programming language(s): Python Pywikibot

トトト (talk) 12:40, 30 August 2024 (UTC)[reply]

Discussion

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

Bot's tasks for which permission is being sought: meta:Global_reminder_bot for Commons

Automatic or manually assisted: Automatic

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

Maximum edit rate (e.g. edits per minute): Roughly expected to be a maximum of ~2-3 edits per day

Bot flag requested: (Y/N): N (the bot already has a bot flag for another task, but the bot flag won't be used for this task)

Programming language(s): Python

A test edit is available at testwiki:User talk:Leaderbot demo.

Leaderboard (talk) 09:16, 22 August 2024 (UTC)[reply]

Discussion

I think this shouldn't be done. We don't make much use of temporary user rights at Commons, and I don't remember even a single case where rights expired without the user noticing it but leading to disruption. If a temporary right expires, it will be extended on request, and it makes no difference if renewal happens before of after it expires. If there are precedents which suggest different, please advise. --Krd 07:36, 29 August 2024 (UTC)[reply]

Hi @Krd: , my experience (at least on Meta) is a bit different - I've seen cases like metawiki:Talk:Steward_requests/Global_permissions/2024#Question happen which was what motivated me to write this bot. Now Commons might be a bit different on that respect, but in my opinion, I see this as a "no loss" situation and while yes the user can renew the rights after expiry, the point is to avoid this disruption entirely especially if it's a right that requires some sort of discussion. Worst case the user ignores the notification. And Commons does appear to make use of temp rights, at least from the user rights log (covering rights such as primarily IPBE, account creator and trials for rights such as autopatroller).
(Note that if the decision is to not approve this bot which I understand, Commons will be placed in the bot's opt-out list which means that no user can opt-in and the bot will be disabled entirely on the wiki. Users can easily opt-out from the bot however if they want) Leaderboard (talk) 09:02, 29 August 2024 (UTC)[reply]
I think worst case is that by the notifications users may request renewal for rights they actually don't need, just because they can. But, I'm just providing feedback and will make any decision here. Krd 06:26, 30 August 2024 (UTC)[reply]
"users may request renewal for rights they actually don't need" - can happen even without a reminder, right? I do appreciate your feedback in any case BTW - this helps when thinking about it for other wikis as well. Leaderboard (talk) 06:37, 30 August 2024 (UTC)[reply]
It can happen anyway, but per my experience the reminders will significantly raise the number of cases. If you look at Commons:Administrators/Inactivity section, the part of users who signed for keeping their right and still was inactive half a year later, has always been significant, and just dropped a bit in the last few years, Krd 02:04, 2 September 2024 (UTC)[reply]

Operator: MFossati (WMF) (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information)

Bot's tasks for which permission is being sought: add the following structured data statement and qualifier to the file page of a new upload that is detected as a logo by this tool.

Automatic or manually assisted: automatic, supervised

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

Maximum edit rate (e.g. edits per minute): it depends on the amount of image uploads and on the amount of images detected as a logo. Hard to tell for now

Bot flag requested: (Y/N): Y

Programming language(s): Python, Pywikibot

Source code: https://gitlab.wikimedia.org/toolforge-repos/gogologo

MFossati (WMF) (talk) 12:19, 24 July 2024 (UTC)[reply]

Discussion
  • I think it'll much better application for bot it it could detect non-trivial logos or logos already deleted. --EugeneZelenko (talk) 14:41, 24 July 2024 (UTC)[reply]
  • Wouldn't it be better to add them with a separate property? While I'm in favor of adding more such ways to identify images, I don't think it mixes well with other statements. This was attempted and finally discarded with "depicts" statement a while back. Please make sure these statements can also be searched with Special:Search. Enhancing999 (talk) 14:53, 1 August 2024 (UTC)[reply]
    Hey Enhancing999, thanks for your comment. Could you please provide any specific pointers to the previous attempt you mentioned? MFossati (WMF) (talk) 11:29, 12 August 2024 (UTC)[reply]
    here Enhancing999 (talk) 11:31, 12 August 2024 (UTC)[reply]
  • Is this bot going to be used as "act once on new uploads", "act once on all existing files", "potentially act more than once on the same file", or what? Unless it only acts exactly once on any given file, what is to prevent it getting into an edit war if its edit is reverted or otherwise changed? - Jmabel ! talk 18:11, 1 August 2024 (UTC)[reply]
    Hi Jmabel, thanks for your question. The bot is expected to act once on new uploads. MFossati (WMF) (talk) 11:31, 12 August 2024 (UTC)[reply]
    • Good. Is there any chance that the bot could also look at the wikitext for {{Own work}} and add a maintenance category (call it Category:Own work logo to checked) if it appears to be a logo and is claimed as "own work"? We see that combination a lot, and it is almost never true. And possibly something similar for a logo + any CC license, because that's usually false as well: we very rarely get a license for any logo that is above the threshold of originality. - Jmabel ! talk 15:15, 12 August 2024 (UTC)[reply]
      I agree that the ability to search for logos plus own work and/or CC licenses would make a lot of sense. I think this is something we can do by querying structured data. For instance, we can already run a query like this to look for own work files with CC BY-SA 4.0. As soon as the proposed logo statements get added, we can then insert a wdt:P31 wd:Q1886349 constraint in the query. MFossati (WMF) (talk) 09:50, 14 August 2024 (UTC)[reply]
  •  Comment As requested by the rules, we've test-run the bot on 100 uploads randomly sampled from uploads made between Aug 21 and today, and here are the results:
    • 4 medias were deleted beforehand, so no edit
    • 1 media was skipped (maximum retries attempted due to maxlag without success), so no edit
    • 95 medias were successfully edited
It seems that it successfully worked, but we'll wait for community review. Sannita (WMF) (talk) 15:34, 30 August 2024 (UTC)[reply]
It appears each file is edited twice. Is that for technical reason, or can the edits be combined in any way? Krd 17:36, 30 August 2024 (UTC)[reply]
Can you use another property than P31 as suggested above? I think we should avoid a re-run of c-a t where WMF mostly ignored community input.
 ∞∞ Enhancing999 (talk) 17:52, 30 August 2024 (UTC)[reply]
Hi @Krd and @Enhancing999, thanks for your feedback and sorry for the late reply, for some reason your replies did not appear in my notifications.
While we wait for @MFossati (WMF) to be back in office for answering the first question, we are open to suggestion as to which property to use. @Enhancing999 do you already have one in mind? Sannita (WMF) (talk) 16:11, 5 September 2024 (UTC)[reply]
You can create one ad hoc.
 ∞∞ Enhancing999 (talk) 17:16, 5 September 2024 (UTC)[reply]

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

Bot's tasks for which permission is being sought: Convert TIFF files to JPEG files and link both. As requested at Convert Commons:Bots/Work requests § Category:Photographs by Carol M. Highsmith to JPEG. The TIFF files at Category:Photographs by Carol M. Highsmith are [recursively] loaded into the bot and converted to JPEG using Wand, a Python binding for ImageMagick. The Exif metadata is copied over using PyExifTool, a Python binding for ExifTool by Phil Harvey. The metadata groups that are being copied over, that I've discovered so far, are: Author, Camera, Composite, ExifIFD, GPS, ICC_Profile, IFD0, IPTC, Location and XMP-crs. The entire metadata can be copied indiscriminately if that is preferred rather a selection. The new JPEG file will have the same wikitext as the TIFF file, with an addition of {{{other_versions}}} gallery and but a removal of categories such as Uploaded by xyz user as it will be retained in the TIFF file page. The TIFF file page is edited with a link to the JPEG in the gallery and all the categories are removed with the addition of Category:LC TIF images with categorized JPGs. If duplicates are found, using the checksum, the page is skipped over and marked for manual verification and linking using gallery. The OpenCV strategy as described at User:Fæ/LOC#Housekeeping is rather out of my reach. The bot is being written using Pywikibot and is intended to run on Toolforge.

Automatic or manually assisted: Automatic

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

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

Bot flag requested: (Y/N): Y

Programming language(s): Python (Pywikibot)

-- DaxServer (talk) 15:07, 1 July 2024 (UTC)[reply]

Discussion
I'm not able to understand the issue we are trying to solve. All previews of these gigantic TIFFs load just fine for me (in under 2 seconds). I do not expencience much difference as compared to JPEGs. --Schlurcher (talk) 14:18, 2 July 2024 (UTC)[reply]
 On hold for the discussion linked -- DaxServer (talk) 08:58, 4 July 2024 (UTC)[reply]
TIF format is an archive format which is simply not suitable for web use, for example TIF file previews look much worse than JPG when used in Wikipedia articles, them being "lossless" dosen't improve the actually displayed quality, it is made worse. "Freely usable media" also means not needing to have very fast internet connections, or needing special programs to edit the files. Another random example: Free email clients allow only very limited attachment sizes (GMail 25MB for example), and sending one document which includes an 100MB TIF image would not be possible for the average person, who has no clue about file formats. TheImaCow (talk) 11:58, 24 July 2024 (UTC)[reply]
The argument appears to be in line Commons:File types. Given that, should we convert all TIFF files, replace their usage, and delete the TIFFs? Krd 07:34, 27 July 2024 (UTC)[reply]
I would generally support that, but I am sure that this would need wider consensus. (as it would also affect these 200k images) TheImaCow (talk) 21:13, 28 July 2024 (UTC)[reply]
I'd appreciate if anybody could start such discussion at a suitable venue. Krd 05:19, 3 August 2024 (UTC)[reply]