The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was Approved.

Fbot 9[edit]

Operator: FASTILY (TALK)

Time filed: 09:51, Monday October 24, 2011 (UTC)

Automatic or Manual: Automatic unsupervised

Programming language(s): Java

Source code available: Not currently

Function overview: Bot tags non-free images (jpg, png, gifs only) with ((Non-free reduce)) if one of the sides is longer than 400px. the image is larger than 164,025 pixels (explanation for this below).

Links to relevant discussions (where appropriate):

Edit period(s): Continuous

Estimated number of pages affected: 20k

Exclusion compliant (Y/N): Y

Already has a bot flag (Y/N): Y

Function details: Bot starts by retrieving a list of files based off template transclusions of non-free templates. Bot then checks each image's size. If the longest side of the image is >= 400, If the image is larger than 164,025 pixels, tag file with ((Non-free reduce)). This task should complement Wikipedia:Bots/Requests for approval/DASHBot 9 nicely. -FASTILY (TALK) 09:51, 24 October 2011 (UTC)[reply]

Discussion[edit]

Image size is recorded on the database, as is category membership. Hence, there is only a need to run a single Toolserver query and tag all of those. Which makes me wonder, why hasn't anyone done that before? Surely someone must have had an objection? - Jarry1250 [Weasel? Discuss.] 16:03, 24 October 2011 (UTC)[reply]

Incorrect parameters - The bot should not be tagging non-free files based on the longer side being greater than 400px. Since not all files are square, any file where [ L x W ≤ 160,000 ] is good. That means 400x400 is of course good, but it also means that 500x320 and 600x266 are good. This is the parameter that DASHBot and the resizing user script both use. If we're going to have a bot do the tagging, I'd actually set the number somewhat higher, so that it would only tag files where [ L x W > 164,025 ] (i.e. larger than 405x405) since I've seen plenty of images resized to 401x400, and that's really not something that's worth re-shrinking. As for the function itself, I support it with the revised parameters. Sven Manguard Wha? 12:29, 30 October 2011 (UTC)[reply]

Approved for trial (30 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Don't see any real problems, task is according to non-free media guidelines and there's a backlog and identifying these by hand requires the aforementioned TS access or at least API. I would personally have the size restriction to some 500x500+ for initial runs until backlog is cleared to a point where we can worry about smaller ones. —  HELLKNOWZ  ▎TALK 10:14, 6 November 2011 (UTC)[reply]

If I come across something that is 500x500, I'll typically resize it on the spot. That's substantially larger than the guideline. At the same time though, if it's just for the trial, I don't see why that's not a problem. The things that were skipped over won't be skipped over in the full run. Sven Manguard Wha? 10:57, 6 November 2011 (UTC)[reply]

Trial complete. Test run = success. We're good to go here. -FASTILY (TALK) 10:26, 24 November 2011 (UTC)[reply]

If I may make a suggestion that in no way impacts whether this gets approved or not: DASHBot, which is going to do the resizings, might get overwhelmed, or might be down at the time that this task starts. I recommend that the two bot operators get in contact and coordinate this, in order to achieve maximum efficiency. Sven Manguard Wha? 11:30, 24 November 2011 (UTC)[reply]

Miss-typed the less than equal to sign. As you can imagine, that would cause some problems :P It's fixed now though. -FASTILY (TALK) 20:47, 24 November 2011 (UTC)[reply]

((BAGAssistanceNeeded)) ? -FASTILY (TALK) 21:26, 25 November 2011 (UTC)[reply]

This looks ugly (notice the <pre> box due to the whitespace). I am aware what a pain whitespace can be, but is there any way you can stop/avoid that happening in future (so far that's the only one I can see, but if the bot is going to be doing a large amount of edits it is bound to happen somewhere else) --Chris 08:25, 26 November 2011 (UTC)[reply]
Added .trim() to the string representing the text of pages retrieved via API. Whitespace won't be a problem anymore. -FASTILY (TALK) 08:57, 26 November 2011 (UTC)[reply]

 Approved. --Chris 02:02, 28 November 2011 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA.
Category