The following discussion is an archived debate. Please do not modify it. Subsequent comments should be made in a new section. The result of the discussion was Approved.

NeuRobot 2[edit]

Operator: — neuro(talk)

Automatic or Manually Assisted: Automatic, supervised

Programming Language(s): AutoIt

Function Overview: Downsizes images in Category:Non-free image size reduction request to 400px on the longest side.

Edit period(s): On and off, will take a good bit of power to run. Probably 30 mins a day.

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

Function Details: The bot will work its way up Category:Non-free image size reduction request, check that the license is non free, check that the image is bigger than 400px on its longest side, and if all of those are confirmed it will download the image and resize it to 400px on its longest side, and reupload, removing the ((Non-free reduce)) template in the process. Before upload, the bot will open the image, resize, and then save as either:-

  • optipng -o7 file.png
  • pngout file.png
  • advpng -z4 file.png
  • pngcrush -brute file.png file_.png

Other image types will be left alone.

The 30 mins a day edit period is mostly processing time - the images will all be processed, and then when I stop the bot I will then tell it to fill in upload forms in batch with 'ignore any warnings' ticked, and all the images will be uploaded. I will sit with the bot whilst it processes the images, so any errors (if they occur) will be caught before they occur. — neuro(talk) 20:56, 14 February 2009 (UTC)[reply]

Discussion[edit]

A few comments:

  1. Why 400px? Wikipedia:Bots/Requests for approval/ImageResizeBot (expired) proposed resizing to fit inside 640x480, and Wikipedia:Bots/Requests for approval/OKBot 4 is approved to tag images over 500px in either dimension. I thought one of the various non-free image guidelines had a recommendation on this issue, but I can't find it now.
  2. A panoramic image of 3000x600 would be resized down to 400x80, which could be fairly useless. A target area might be better than a target linear dimension (e.g. 894*179 has approximately the same area as a 400x400 image), or else a minimum linear dimension the bot won't go beneath.
  3. Instead of removing ((Non-free reduce)), it should be replaced with ((Non-free reduced)). Consider adding a bot=1 parameter to the template that would include language making it explicit that more-than-usual human attention should be given before deleting the old versions.

This request should probably be advertised at WP:VPR (and possibly WT:NFCC and/or other relevant talk pages) to ensure there is consensus, particularly for the target size chosen (however measured). Bots enforcing the non-free content criteria have historically been controversial for various reasons. Anomie⚔ 23:09, 14 February 2009 (UTC)[reply]

  • ((Non-free reduced|bot=1)) replacement now implemented. 400px was what I thought was about right (I can't find the specific wording either). As for 3000x600 images - surely they are not permitted through NFCC anyway? Much too big in both dimensions, at least in my eyes. I will advertise this at VPR and NFCC in a moment. — neuro(talk) 23:45, 14 February 2009 (UTC)[reply]
  • Advertised. ([1][2]) — neuro(talk) 23:51, 14 February 2009 (UTC)[reply]
    I seem to remember a passing mention of something like ".25 megapixels" (which would be 512x512, or about 1144x228 for our panorama example), but I could easily be misremembering. As for 3000x600, it would certainly be too big for our NFCC, but shrinking to 400x80 might be overdoing the reduction; would reducing to only 80 pixels high leave enough detail? I can't find the edited ((Non-free reduced|bot=1)) to comment on that. Ads look good. Anomie⚔ 23:59, 14 February 2009 (UTC)[reply]
  • Hm, I could always tell it to ignore images with a high aspect ratio, if is what consensus indicates is wanted. — neuro(talk) 00:04, 15 February 2009 (UTC)[reply]
  • It shouldn't be hard to add code to check if the width × height is greater than an agreed upon total size (megapixel) should it? The bot could then handle the odd cases where an image is much wider/taller correctly (as the algorithm to reduce should take into account the odd size, and not simply reduce the image to 400px). —Locke Cole • t • c 17:13, 17 February 2009 (UTC)[reply]

The size should depend on actual usage. The bot should be smart enough to check current usage, then size to that, or at most, 2x of that. To prevent accidental undersizing because a vandal mucked with the in-use sizes right at the moment the bot checked, sample the in-use several times over a period of a week and only make the reduction when the in-use sizes are stable for a week. For images used in templates, figure out what the size is in the template. For images used in thumbs, assume 300px, which is the larges size supported by thumbnails. If "oh, but people may need to expand it to see fair-use-rationale-supported detail" is an issue, then I'd be okay with up to 900 pixels. Remember, we are talking non-free images here, there's generally no reason to have it any larger than it appears on the screen. By the way, I support this as a task suitable for a bot. davidwr/(talk)/(contribs)/(e-mail) 02:14, 15 February 2009 (UTC)[reply]

  • "For images used in templates" - NFCC images are not allowed in templates, so this isn't a problem.'
  • I meant images utilized in templates, such as album covers, tv show stills, etc. that are typically used in infoboxes. davidwr/(talk)/(contribs)/(e-mail) 14:33, 15 February 2009 (UTC)[reply]
  • As for the 'vandal resizing' comment, I don't see why the resolution which it is resized to should be determined by the thumb size. 400px on one side seems about right to me for all circumstances - images should also be able to be seen at higher resolutions when thumbs are clicked on (due to the very nature of thumbs). 400px still seems suitable to me, but I'm flexible if others suggest otherwise. — neuro(talk) 12:10, 15 February 2009 (UTC)[reply]
  • By the way, am I missing something, or does ((Non-free reduced|~~~~~|bot=1)) have no other effect than without the bot parameter? Or is it wanted that bot=1 is implemented? — neuro(talk) 12:53, 15 February 2009 (UTC)[reply]
  • For non-thumbs, actual in-use size may be > 400px, you need to check for that. For many non-free images, an appropriate size is well under 400px. The maximum size of a non-free image should be the size that has enough detail for its use. For some images, it's 300px, for some, 600px, for some, such as very skinny picts, 1200 or more. For others, such as simple logos or spot-color work, 100px is enough. In general, the size people see on the screen is enough, although for some thumbs that is insufficient. davidwr/(talk)/(contribs)/(e-mail) 14:33, 15 February 2009 (UTC)[reply]
  • Very few NFCC images would be permitted to over 400px in thumbs. Bot is now set to flag all that are over 400px in thumbs before I set it to upload. I will check the use - if 400px is an unsuitable thumb size I will tell the bot to force it to an appropriate size (determined by myself), and then upload, if not I would reduce the image to the size used in the article, if that didn't already apply. — neuro(talk) 14:58, 15 February 2009 (UTC)[reply]

I thought of another issue: Use the same dimension-resizing algorithm Wikipedia uses to present images at a smaller size. I you don't, the image you generate may look distinctly different than what Wikipedia generates, which can cause arguments from people who preferred the Wikipedia-generated reduced-size image. When I shrink non-free images, I preview a page that shows the image at the size I want, then save the image or take a screen-shot. I found this out the hard way with File:Betsy's_Kindergarten_Adventures.jpg - the program I used to shrink the file from 727px to 300px created a much sharper and more contrasty version than Wikipedia, I I switched to using the Wiki-generated version. The bot should be able to do this through the API. davidwr/(talk)/(contribs)/(e-mail) 14:33, 15 February 2009 (UTC)[reply]

  • "the image you generate may look distinctly different than what Wikipedia generates" - I find this hard to believe. Could you demonstrate this for me? I've just had a play with a local MediaWiki installation, and I am unable to replicate it. — neuro(talk) 14:53, 15 February 2009 (UTC)[reply]
  • As an aside, I wonder if the resize method Wikipedia uses is available separately from MW? If so, I could run it locally, which would be optimal. — neuro(talk) 15:00, 15 February 2009 (UTC)[reply]
    Based on CommonSettings.php and includes/media/Bitmap.php, it seems that Wikipedia uses ImageMagick to resize raster images; generally, the command seems to be convert -quality 80 -background white -size width source -thumbnail widthxheight -depth 8 [-sharpen 0x0.4] dest for jpeg and the same with -quality 95 (and never -sharpen) for png. I don't know which version or if there are any patches applied, and it's possible I could be wrong about something in there. Note also that different results may be given for MediaWiki reducing directly from 800x600 to 180x135 than for a two-step reduction to 400x300 and then to 180x135. Anomie⚔ 16:31, 15 February 2009 (UTC)[reply]
  • Well then, I will happily use that if that is wished for. — neuro(talk) 16:32, 15 February 2009 (UTC)[reply]

After you get this working, can you host the bot somewhere for on-demand conversion? This way, if I see a file that someone uploads next week that's oversized, I can go to a web site, type in the name of the file, have it recommend a size based on the current usage, then set it to whatever size I type in? Ideally, it would automagically upload the "non-free-reduced" template to alert an administrator to delete the old version after 7 days. davidwr/(talk)/(contribs)/(e-mail) 19:29, 15 February 2009 (UTC)[reply]

Unfortunately not, various issues with that (for one the language inflexibility). — neuro(talk) 02:16, 16 February 2009 (UTC)[reply]

Will the original versions remain in the archive? If for any reason the processed image is later found to be unsatisfactory it would be good if the processing could be redone. This is a problem that could arise with images that are not sourced from online. Originally scanned from a book, for instance, and the original uploader has moved on long ago. SpinningSpark 19:55, 15 February 2009 (UTC)[reply]

If the bot simply uploads the resized image as a new version of the original (which I think would be the best idea), then yes, the original stays in the history. See this image for just one example, scroll down to 'File history'. Richard0612 20:15, 15 February 2009 (UTC)[reply]
Thanks, but I know how file history works, the question was prompted by a half-implication in the conversation above that admins would delete the original after the upload. SpinningSpark 21:52, 15 February 2009 (UTC)[reply]
I would hope admins would wait the usual 7 days before deleting the old version. The bot should add the appropriate non-free-resized or similar dated template to alert admins. davidwr/(talk)/(contribs)/(e-mail) 00:07, 16 February 2009 (UTC)[reply]
And it will, as mentioned above. — neuro(talk) 00:31, 16 February 2009 (UTC)[reply]
It is not usual to delete anything from the history. The implication of those comments is that the resized file is uploaded to a different name from the original and then the original is deleted after seven days. I do not think this is a good idea. It is better just to push the original back down in the history so it is still there if there is a problem. Seven days is just not long enough for the more obscure articles. I have come across many electronic articles, for instance, where a circuit diagram was uploaded years ago before we took so much care over copyviolations. I have the capability of producing my own electronic diagrams to replace them if needed, but so often I find that the image has been deleted months ago for inadequate licencing information with no hope of recovery. It would be a shame if the same sort of thing started happening here. SpinningSpark 13:09, 16 February 2009 (UTC)[reply]
A little clarification is in order - I am uploading to the same filename, not uploading to another. — neuro(talk) 13:28, 16 February 2009 (UTC)[reply]
  • Would it ease your concerns if I set the bot to notify me of each upload before it did them, and I were to verify for each one that it would not compromise the quality of the image to be resized? — neuro(talk) 11:43, 16 February 2009 (UTC)[reply]
  • If the number of changes is small enough that you can sanity-check each and every one before committing it, then do so. By the way, sometimes non-free images are non-free precisely because they contain copyrighted text, and making the text illegible is the right thing to do. I did this a few weeks ago with a historical-marker sign that was mistakenly uploaded as a "free" image: The copyrighted text of File:MichiganHistoricalSign.jpg was not eligible as non-free content in Bath School disaster, so I scaled the image down so the image could be free as the uploader intended. I also found a legitimate/non-copyvio Google Books link to the copyrighted text and put it in the text part of the file and as a reference in the article. davidwr/(talk)/(contribs)/(e-mail) 18:15, 16 February 2009 (UTC)[reply]
  • Agree that images with text should not be reduced (movie posters, etc) as they're often already difficult to read usually. —Locke Cole • t • c 17:09, 17 February 2009 (UTC)[reply]
  • Agree, and there should be some way of flagging images for immunity to the bot. Images of advertising for defunct businesses (e.g. File:Mark eden bust developer.jpg) are almost entirely text. While copyrighted, the likelihood of actual prejudice to copyright is minimal, given that the product can no longer be sold, the text was made for promotion, and the purpose of using it is to illustrate the claims made in advetising the product. The same is true of a number of other images (e.g. File:Mickey mouse acid warning.png which must be uploaded as fair use even if no copyright owner can be identified (the image also contains a crude drawing of Mickey Mouse). This sort of image ought to be immune to its operation. - Smerdis of Tlön (talk) 15:49, 23 February 2009 (UTC)[reply]
  • Posted with permission, for clarity:

15:56 < Neurolysis> Richard0612: If I get approved for trial (which looks likely), would uploads count as edits?

15:56 < Neurolysis> Because the bot uploads the file and edits the page, you see.
15:56 <+Richard0612> Ah, good point.

15:58 <+Richard0612> Neurolysis: Personally, I would say that uploading the file and then editing the page to reflect the resizing counts as one /action/ and therefore if the bot was approved a 20 edit trial, that would mean 20 uploads, and 20 edits to reflect those uploads

— neuro(talk) 16:03, 17 February 2009 (UTC)[reply]
Approved for trial (10 uploads; trial also includes editing the image page to reflect the resizing). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Seeing as each upload is going to be checked manually, and (as far as I can see) the concerns raised above have been addressed, I see no reason not to approve a trial and see how things go. Richard0612 23:58, 18 February 2009 (UTC)[reply]
Trial complete. — neuro(talk) 01:22, 19 February 2009 (UTC)[reply]
Two issues encountered, both minor and resolved - I forgot to reimplement optimising the PNGs after I changed some code, now readded and confirmed working, and also, the bot failed to log out, so my comment came through under the bots account (now re-signed) - issue now resolved. — neuro(talk) 01:28, 19 February 2009 (UTC)[reply]
Fixes to my original wording. — neuro(talk) 01:52, 19 February 2009 (UTC)[reply]
Recommend adding of log output to a page we can watchlist. The log should include wikilinks to the files. For the first few hundred edits I and others will probably want to spot-check to make sure 450px isn't too small. Also recommend approval for an extended trial of 1 week or 1000 images, whichever comes first. davidwr/(talk)/(contribs)/(e-mail) 05:20, 19 February 2009 (UTC)[reply]
I tried to implement this earlier and it bugged out on me. Any reason why Special:Log won't suffice? — neuro(talk) 11:50, 19 February 2009 (UTC)[reply]
Once the bot runs under a dedicated account, spedial:log will be fine. davidwr/(talk)/(contribs)/(e-mail) 14:35, 19 February 2009 (UTC)[reply]
Define 'dedicated account', please. 'Dedicated' doesn't seem to make sense in the context - and what I would assume it means is already the case. — neuro(talk) 16:32, 19 February 2009 (UTC)[reply]
I mean a bot account, one where Special:Log with the bot-account name will show only the bot's edits, not your edits. Sorry for the linguistic confusion. It's very clear that Neurolysis (talk · contribs) is dedicated to the project :). davidwr/(talk)/(contribs)/(e-mail) 18:23, 19 February 2009 (UTC)[reply]
That's what I thought you meant. :) That is already the case. — neuro(talk) 18:46, 19 February 2009 (UTC)[reply]
An, I see: NeuRobot (talk · contribs) davidwr/(talk)/(contribs)/(e-mail) 20:09, 19 February 2009 (UTC)[reply]

Please summarize post-trial-1 algorithm here[edit]

Please say what you and the bot do each run here. Thanks. davidwr/(talk)/(contribs)/(e-mail) 05:21, 19 February 2009 (UTC)[reply]

Okie dokie:
  • The bot gets the names of the first 200 files from Category:Non-free image size reduction request
  • The bot then asks me how many I wish to process (say for this, I select 50)
  • The bot then looks at the first 50 image pages, and checks for any pending deletion (like PUI, IfD or orphan) notices. If it finds these notices, it skips that image. (So if there are 50 I am getting, and three are pending deletion, it will download 50 images from the first 53 in the category).
  • These downloaded images are then put in /downloads/, and are copied to /todo/.
  • The bot then opens up an image viewer for all images /downloads/, so that I can compare before and after quickly.
  • Two batches are then run on /todo/. One processes portrait images, one processes landscape images.
  • The files are then moved to /done/.
  • The bot then opens up another image viewer, and aligns the earlier one and this one side by side, so that I can compare.
  • If the reduction is too great to be sensible, I delete the image. If the reduction is ok, I leave the images in /done/.
  • The bot then opens up the same number of instances of Special:Upload, inputs the file names, and adds the summary.
  • The bot then begins to upload the images.
  • As soon as uploading has started, the bot opens up the original image pages and replaces ((Non-free reduce)) with ((Non-free reduced)).
  • The bot then checks that all images have uploaded successfully, and proceeds to delete all images in /NB/ (which includes in subfolders /done/, /todo/ and /downloads/).
— neuro(talk) 11:49, 19 February 2009 (UTC)[reply]
Bot no longer optimising with PNGCRUSH or PNGOUT due to wildcard issues. OptiPNG and ADVPNG are still being used, batch source here. — neuro(talk) 16:58, 19 February 2009 (UTC)[reply]
information Note: On-demand resizing now implemented at User:NeuRobot/Requests, instructions in source for now, will make a template and add it to the top of the page in a moment. — neuro(talk) 18:12, 19 February 2009 (UTC)[reply]
Approved for extended trial (500 images or 1 week). Please provide a link to the relevant contributions and/or diffs when the trial is complete.
Extended trial to ensure that the code works in all cases and so that users can monitor the bot's output and give feedback in a central place, as per davidwr's recommendation above. Richard0612 19:17, 19 February 2009 (UTC)[reply]

Size parameters need to be changed[edit]

The convention at Wikipedia:Non-free content has always been that non-free images should be about 0.1 megapixels or smaller. This idea that images should be less than 450, 400, or 300 pixels on a side is not accurate and will cause problems for images with non-standard aspect ratios. Please change the algorithm for this bot to:

  1. Only resize images which are significantly larger than 0.1 megapixel (for example, an image that is 1000x100 pixels should not be resized)
  2. Resize the images to 0.1 megapixels (for example, an image that is 2000x100 pixels should be resized to 1414x71 pixels rather than 450x23 pixels)

Alternately, you could just have this bot exclude images which have aspect ratios greater than 2:1 or images for which either side is already 200px or less. Either of those approaches should avoid most problem images. Kaldari (talk) 18:45, 23 February 2009 (UTC)[reply]

Should images in certain categories be resized smaller than in other categories. e.g. File:1st Class cover.jpg was resized by the bot & then resized again to an even smaller size. -- WOSlinker (talk) 22:36, 23 February 2009 (UTC)[reply]
Another question, should the bot resize images where there is only a small reduction in size from the previous version. e.g. File:2003 Quebec general election, Le Devoir.jpg -- WOSlinker (talk) 22:43, 23 February 2009 (UTC)[reply]
The criteria is that images be of "low resolution" - what is a sufficiently low resolution is subjective and varies from case to case. For example, it would be perfectly appropriate to have an 800x600 screenshot of a non-free operating system. Even though 800x600 is a bit larger than most non-free images, it is a minute fraction of the overall operating system and newer operating systems generally cannot be completely or accurately displayed at less than 800x600 resolution anyway. —Remember the dot (talk) 01:53, 24 February 2009 (UTC)[reply]
I agree that the size needs to be determined based on width × height (the megapixel size), however, I disagree that the convention should be 0.1 megapixels. Is this 0.1 megapixel size codified anywhere within policy? I think something between 0.25 – 0.4 megapixels (480×480 – 640×480) is more reasonable. A bot definitely shouldn't be resizing images until there is agreement on this. Also concur with RTDs comment above regarding screenshots. —Locke Cole • t • c 19:33, 26 February 2009 (UTC)[reply]
Well, if someone would tell me how to do that using ImageMagick, please feel free to. If you want it resized based on overall resolution as opposed to dimensions then I need some instructions - I've never known ImageMagick as being capable of performing such a function. — neuro(talk) 03:00, 27 February 2009 (UTC)[reply]
Is the code for this bot available somewhere? —Locke Cole • t • c 03:59, 27 February 2009 (UTC)[reply]
Nevermind. Here is what you're looking for. Geometry is the parameter to -resize in Imagemagick, and here's the passage we're concerned with:
Finally, use @ to specify the maximum area in pixels of an image, again while attempting to preserve aspect ratio. (Pixels take only integer values, so some approximation is always at work.) In the following example, an area of 10000 pixels is requested. The resulting file has dimensions 115x86, which has 9890 pixels.
$magick> convert logo: -resize '@10000' wiz10000.png
So you need to use this @ syntax, with the number following the @ being the number of total pixels. Imagemagick will respect the aspect ratio of the image for you automatically. From my comments above, 0.4 megapixels would be "-resize '@400000'"; 0.25 megapixels would be "-resize '@250000'". Try this out (I don't have Imagemagick installed or I would) and let me know how it goes. =) —Locke Cole • t • c 04:11, 27 February 2009 (UTC)[reply]
Okay, implemented. All I need is some sort of consensus on how many megapixels to use. — neuro(talk) 07:25, 27 February 2009 (UTC)[reply]
Until that time, if you plan to continue running tests, I'd suggest being conservative and using 0.4 megapixels (reasoning for me being that if the consensus ends up being larger and fair-use histories have been deleted then there's no way to undo your work; but we can always go smaller if that's what happens). —Locke Cole • t • c 08:45, 27 February 2009 (UTC)[reply]
I'd place the upper limit at 0.48 megapixels (800x600) to be on the safe side. —Remember the dot (talk) 19:15, 27 February 2009 (UTC)[reply]
I support that. —Locke Cole • t • c 19:20, 27 February 2009 (UTC)[reply]
Personally, I think that is way too high. I was thinking say, 3.5? — neuro(talk) 21:41, 27 February 2009 (UTC)[reply]
You mean 0.35? =) I think RTD suggested 800×600 because many screenshots are at (or near) that resolution and making them smaller would make them unintelligible. For something that's automated we want care to be used (and it's better to err on the side of caution for something that's destructive like this than to get it wrong). —Locke Cole • t • c 21:59, 27 February 2009 (UTC)[reply]
As has been stated before, all resizes are manually reviewed by myself. As for the screenshots thing - it depends on what is being illustrated. Often lower than 800x600 is appropriate. — neuro(talk) 22:58, 27 February 2009 (UTC)[reply]
Trial complete.
The trial is over, but I didn't get to do so much due to huge memleaks in an app being utilized, so no more tests until I get a green flag from BAG. — neuro(talk) 17:09, 27 February 2009 (UTC)[reply]
So we are talking about it running on PNGs and JPGs of .35 megapixels, right? If so I will be approving when I wake up tomorrow. MBisanz talk 08:11, 1 March 2009 (UTC)[reply]
Resizing to .35, yes. Personally, I'd like .25, but I don't know if consensus is leaning that way. .35 is 700 x 500, which is much, much too big. — neuro(talk) 02:12, 2 March 2009 (UTC)[reply]
Don't approve just yet please - I am implementing use of PYWB which I am not so familiar with, so I will probably need another trial once I've got it set up. — neuro(talk) 05:17, 3 March 2009 (UTC)[reply]
Ok, we will hold off. MBisanz talk 06:05, 6 March 2009 (UTC)[reply]
I think larger consensus is needed before it is decided what the bot should resize images to. I will get something going in a few days to that effect. If possible, leave this open, but feel free to remove it from the main BRfA page if you want (although I don't mind either way), as I feel closing it and having to start all over again might be more problematic than waiting upon seeing what the consensus is. — neuro(talk) 05:58, 11 March 2009 (UTC)[reply]
Thought I mentioned it here, but apparently not - I started an RfC. — neuro(talk) 19:09, 16 March 2009 (UTC)[reply]
There haven't been any further comments at that RFA in about a week. Do you feel you have enough feedback to proceed? – Quadell (talk) 14:07, 2 April 2009 (UTC)[reply]
I have commented to stop it being archived, but I don't see consensus. — neuro(talk)(review) 01:47, 6 April 2009 (UTC)[reply]

Well, what do you want to do here? – Quadell (talk) 14:03, 20 April 2009 (UTC)[reply]

I believe that batch resizing to 0.25mp should be fine since I do have the chance to review the images anyway (it is not fully automated, I still check that everything is ok, and use my judgment in deciding whether the resize is appropriate). — neuro(talk) 14:33, 25 April 2009 (UTC)[reply]
I intend to approve this soon, if no one objects in the next few days. – Quadell (talk) 01:51, 27 April 2009 (UTC)[reply]
If he's doing it in such a way that it is semi-automated, why does he need the bot flag? Also, there is still unresolved discussion about whether 0.25 is large enough; edits marked as bot edits should have something resembling consensus behind them. —Locke Cole • t • c 03:13, 27 April 2009 (UTC)[reply]
I believe these edits do have "something resembling consensus behind them". An RFC was opened, and there was much discussion, and discussion died off. Most commenters wondered if .25 was too large, not too small. I understand you disagree, of course. – Quadell (talk) 11:01, 27 April 2009 (UTC)[reply]
My reason for requesting the bot flag was mostly because all actions (except for accept/deny) are done automatically, and uploading an absolute ton of images without a bot flag will cause a nightmare at Special:Newfiles. — neuro(talk) 09:55, 29 April 2009 (UTC)[reply]
As an aside, I have implemented use of AWB to change the reduce request, as the old code was inefficient as hell. I assume bots would need to be added to the checkpage as well. — neuro(talk) 09:59, 29 April 2009 (UTC)[reply]

 Approved. Looks good. – Quadell (talk) 13:10, 29 April 2009 (UTC)[reply]


The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section.
Category