Jump to content

Wikipedia:Administrators' noticeboard/Betacommand/Archive 4

From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4

Bot needs to be blocked

BetacommandBot needs to be blocked until it correctly processes {{nobots}}. I added the tag some time ago to my userpage in the hopes it would stop notifying me and yet it continues to do so (BTW, {{nobots}} compliance ought to be a requirement of being given bot status/approval). —Locke Coletc 22:04, 8 March 2008 (UTC)

Well complying with the nobots tag is currently not a requirement for bot operation, so demanding that a bot be blocked for not complying is a non-starter. BetaCommand has a manualy updated list of users not to notify though, you can ask him to add you to it. That said I would encourage BetaCommand to reconsider his position of not supporting the nobots thing. If a user spesificaly deny all bot aceess to his talk page it's easy enough to dismiss any complaints about not beeing notified, and it might reduce the number of "spamming" complaints against the bot, but ultimately it's up to him as long as nobots compliance is strictly optional. --Sherool (talk) 23:56, 8 March 2008 (UTC)
Ive had to override the usage of nobots due to it being miss used. Ive had users attempt to but that on an image instead of a rationale. so I cannot honor the nobots due to known cases of abuse. βcommand 23:58, 8 March 2008 (UTC)
Would it possible to honour nobots on user talk pages only? Will (talk) 00:00, 9 March 2008 (UTC)
Then the editors using the tag incorrectly need to be confronted and/or encouraged to stop. But ignoring the tag outright is not the correct way to go. —Locke Coletc 00:16, 9 March 2008 (UTC)
It's the de facto standard way to keep bots off of a page. Betacommand says it was being abused by being placed on image pages and so forth, and while that's an issue that needs consideration (discuss with the people inappropriately using the tag, block them if they persist), it doesn't excuse ignoring the tag entirely. Until this obvious error is corrected, the bot should be blocked. —Locke Coletc 00:16, 9 March 2008 (UTC)
you seem to misunderstand that nobots is not required to be followed. BCBot pre-dates that template also. βcommand 00:17, 9 March 2008 (UTC)
And making nobots compulsory is a bad idea. For example, think of what would happen if ClueBot followed nobots? Will (talk) 00:19, 9 March 2008 (UTC)
Exceptions to the rule don't make the rule invalid. A corner case can be found for almost any rule (just look at all the corner cases this bot routinely ignores while blindly tagging images when they could be easily fixed in an automatic fashion). —Locke Coletc 00:29, 9 March 2008 (UTC)
And many images that you tag were uploaded long before these rules were actively enforced. I fail to see the difference. And again, it is a de facto standard, so processing it would be more helpful than not processing it. —Locke Coletc 00:29, 9 March 2008 (UTC)
Some bot processes clearly need to ignore the {{bots}} template. It's arguably a nice thing for a bot to check before dropping non-essential notices on user talk pages, but it is, nevertheless, optional. Gimmetrow 00:23, 9 March 2008 (UTC)
Again, it is a de facto standard (and IMHO, should be a requirement unless an explicit exception is granted). —Locke Coletc 00:29, 9 March 2008 (UTC)
Should be, but, is not. WT:BOTS is the second door on the left. I see no reason, to block BetacommandBot over something, that while it is a good practice to engage in, is not a requirement. FWIW, none of my bot process honor {{nobots}} either. SQLQuery me! 00:43, 9 March 2008 (UTC)
If you go up a couple threads on this page though, there is a discussion that appears to have the consensus that BCB should respect NoBots. I don't think your bot's non-compliance has ever been questioned. MBisanz talk 02:33, 9 March 2008 (UTC)
If true, wouldn't noncompliance be something to block over? Or does Wikipedia not operate on consensus anymore? —Locke Coletc 02:36, 9 March 2008 (UTC)
I've started a discussion at the talk page you linked to. —Locke Coletc 02:36, 9 March 2008 (UTC)
I do not support blocking BCB for this reason. It's not a requirement - I could argue that it's a courtesy, but BC has created an alternative process for the same result. Until/unless it's created as policy, I would argue against extending a block for this reason. What's fair about changing the goalpost in mid-stream? - Philippe | Talk 02:38, 9 March 2008 (UTC)
What's fair about getting spammed even after leaving a note on BetacommandBots talk page requesting further notifications be suppressed (and being told I should place {{nobots}} on my user talk page)? I've done everything I can do, now it's time to ratchet things up until he complies with what is a de facto standard (and seems to be the consensus with regards to this bot). —Locke Coletc 02:43, 9 March 2008 (UTC)

Considering the proposal to require BetacommandBot to acknowledge and follow the bots/nobots tags above doesn't close until March 12, the bot doesn't have to do so right now. See a few sections up at Wikipedia:Administrators' noticeboard/Betacommand#Community proposal to Support/Oppose the proposal. And to Betacommand, just because your bot was here before the bots/nobots tags doesn't mean you don't have to follow it or couldn't follow it. Stop being rude. Secondly, I know you can program the bot to ignore bots/nobots tags on image pages but not ignore them on user/user talk pages. Why are you so against this?? - ALLSTAR echo 02:45, 9 March 2008 (UTC)

I do have a method to opt out, if you have a valid reason for not getting messages, (you did a lot of image vandalism reversion, resizing, ect) I will gladly opt you out. but if your just lazy im not inclined to opt you out. I currently have 23 users who have chosen to opt out for good reason. βcommand 02:50, 9 March 2008 (UTC)
You've missed the point. If your bot would follow the bots/nobots tags, there wouldn't be a need to "manually" do anything. Maybe it's you who are lazy by not implementing the tags? Saying that because a user doesn't do image work they are a lazy user, is rude on your part. I want your bot to stop removing categories from my user and user talk pages and so does other users. Make it happen please. - ALLSTAR echo 02:55, 9 March 2008 (UTC)
you ignore our deletion policy, yet expect to be able to force an optional bot procedure on others? that makes no sense. I would consider it rude attempting to force a bot operator to write code for a method that is crap, and has been known to be abused. I have a method for opting out. that is what I choose to do. βcommand 03:03, 9 March 2008 (UTC)
(ec)And this is exactly why bots should be forced to obey {{bots}} (etc). You shouldn't get to be the arbiter of who does and doesn't get messages on their talk page. —Locke Coletc 02:55, 9 March 2008 (UTC)
While I agree that it would be nice for bots to follow {{bots}} and similar templates, especially for BetacommandBot, they should do so knowing the consequences (they may get "their" images deleted without them knowing). I do feel users should be able to opt-out of all bots unless there's a good reason not to but only if they know the consequences. x42bn6 Talk Mess 03:02, 9 March 2008 (UTC)
Again, I'm not talking about BetacommandBot's image work. The bot can be coded to ignore bots/nobots on image pages but to not ignore bots/nobots on user/usertalk pages if the bot is just there to remove a category. If it's there to leave a notice about it having tagged an image, it can then ignore the bots/nobots tag. It's simple. As a network admin, I know it's simple and it definitely should be simple for someone like BC who writes code. - ALLSTAR echo 03:05, 9 March 2008 (UTC)
Allstarecho, parsing templates is extremely difficult to parse, I avoid parsing them at all cost. Just ask messedrocker about RFC bot. Like I have said I have a very reliable method for opting out, and that is what I use. βcommand 03:10, 9 March 2008 (UTC)
Is your bot built around Pywikipediabot? Supposedly that framework supports this, if nothing else, you could look at the code to see how hard it might be to port to whatever your bot is written in. AWB also supports it. —Locke Coletc 03:14, 9 March 2008 (UTC)
Like I said pywiki does support this, but due to large amounts of abuse from this I had to override the default procedure. that is why I use a different method to opt out. βcommand 03:16, 9 March 2008 (UTC)
Perhaps you should fix the code to allow it to only be processed if found in the User_talk namespace. That would satisfy me (and I suspect most other people). —Locke Coletc 03:20, 9 March 2008 (UTC)
why not just use a better method that already exists, instead of a broken system? βcommand 03:23, 9 March 2008 (UTC)
What is this "better method"? —Locke Coletc 03:25, 9 March 2008 (UTC)
my opt out. that has been in place for months. βcommand 03:27, 9 March 2008 (UTC)
Unless I'm missing something, how is this better than complying with {{bots}} only on User_talk pages? Your "opt out" requires you manually adding someone to a list, yes? It's easier on all involved if the code simply checks the User_talk page for the appropriate template isn't it? —Locke Coletc 03:30, 9 March 2008 (UTC)
Ok, the issue seems to hinge on that BCB currently is not compliant with NoBots because of abuse of the template in general led to it being overridden and it would be difficult to re-implement just on a user-talk/user basis. Could we try the Signpost approach? Could there be a page that users could add themselves to that is automatically (by which I mean all names, not those with a reason) are added to BCB's internal non-post list? MBisanz talk 03:37, 9 March 2008 (UTC)
(undenting) That's no different from using {{nobots}}. If you don't want a message from BetaCommandBot then as BC to add you to the opt out list. It's really quite simple. Mønobi 04:46, 9 March 2008 (UTC)
We're going in circles. I've already requested on the bots talk page to not be notified of future issues on my user talk page. I was told I could try adding {{nobots}} to my user page, and I did. I have subsequently received notifications from his bot, despite requesting no more messages and adding {{nobots}} (or rather, {{bots}}, explicitly denying BetacommandBot). What more can I honestly be expected to do? No, the issue here is simple: BetacommandBot can implement the de facto standard method for bot exclusion and ignore it on non-User_talk pages. It's simpler, easier, and doesn't require the user to bend over backwards and lick the back of their heels to get it working. —Locke Coletc 05:02, 9 March 2008 (UTC)
Perhaps BetacommandBot should follow a "nobots" tag or have a signup list to prevent messages on user pages. But Betacommand will take requests to put users on an "opt out" list. This is not the most pressing issue for the community or Betacommand to solve at this time. It is not worth a block. (There are other issues that the community should insist that Betacommand resolve.) -- SWTPC6800 (talk)
As I already said, I requested exclusion on his bots talk page and was directed (by another editor) to try {{nobots}}. Obviously that did not suffice, because I continue to receive notifications. Note here that not only did he not add me to his exclusion list as you're saying he would, but that his bot also willfully ignored {{bots}}/{{nobots}}. This is an unacceptable state of affairs and needs to be remedied before the bot continues. —Locke Coletc 05:32, 9 March 2008 (UTC)
Its not yet a blockable issue from where I see it. This oddly enough sounds like the kind of thing that could benefit from WP:MEDIATION since its relatively distinct from all the other hubbub on this page. MBisanz talk 06:04, 9 March 2008 (UTC)
Mediation would be great if it were just a problem for me: but there are many editors who don't want messages from BetacommandBot on our user talk pages and are ignored (or told to try {{nobots}}/{{bots}}, to no success). As to the severity of the issue, again, it may not seem like the most annoying thing in the world for a bot to do, but I'm pretty well fed up with this bot and the notifications from it. So much so that I'm very serious about making {{bots}} compliance mandatory for all bots that leave notification messages (at a minimum, ideally they would obey it in all cases). —Locke Coletc 06:09, 9 March 2008 (UTC)
Well right now compliance is not mandated by Bot policy, nor is it a technical matter that the BAG has mandated. If the goal would be change wider than just BCB, then a Policy RfC might be the best route. MBisanz talk 06:16, 9 March 2008 (UTC)
(ec)See Wikipedia_talk:Bot_policy#nobots (which I've announced at WP:VPP and WP:VPR as well as within {{Cent}}). I'll see about an RFC as well... —Locke Coletc 06:19, 9 March 2008 (UTC)
Agreed that the bot should not be blocked for this - but only because it is not in violation of policy. BCB *should* be doing this. If there's major problems, maybe we should be reviewing which pages transclude nobots - for example, it would be possible to remove the tag from all spaces except User talk:, Talk: and WP project pages. Orderinchaos 08:24, 9 March 2008 (UTC)

Another way to prevent BCBot from dropping templates on your talk page--this being the best option for the encyclopedia, the way that causes less work for everyone else--is to go fix your image uploads to comply with policy, or tag them for deletion. As an aside, starting out a request for Betacommand to do something by first asking for his bot to be blocked is probably not the best route, though it seems to be a popular one. LaraLove 17:56, 9 March 2008 (UTC)

The issue here isn't just the bot's image work or image tags. The bot also removes deleted or non-existant (aka redlinked) categories from user/user talk pages. The bot simply should follow bots/nobots regarding its user cat work. Again, it can be coded to ignore bots/nobots when doing image work but to respect bots/nobots when doing user cat work. - ALLSTAR echo 20:58, 9 March 2008 (UTC)

Arbitrary break above a box

I ALREADY ASKED ON THE BOTS TALK PAGE TO NOT RECEIVE NOTIFICATIONS, YET I STILL RECEIVE THEM. Asking for him to be blocked IS THE NEXT LOGICAL STEP when he insists on ignoring requests to be left out of notifications. How many times MUST I restate this? I've only said it a half dozen times above: I HAVE EXPLORED ALL OPTIONS AVAILABLE TO ME THAT I AM AWARE OF, and he is either unwilling or unable to stop, neither of which is an acceptable excuse for continuing to harass me (which is what it's turned in to IMO). As to fixing the images, some of them have been fixed, others were uploaded back when this wasn't a requirement (or at the least, it wasn't preached as it is now). I refuse to be constantly told I must jump through hoops to keep images on Wikipedia because it is an ever moving target where the goalposts are constantly being moved to wonderful new locations. First it was sources, which I was happy to comply with. Now it's rationales (even for obvious materials like logos). What's next? Stand on my head, pat my belly and slap my knee at the same time without falling over? —Locke Coletc 21:13, 9 March 2008 (UTC)
I heard you, I made an opt out list that can be used for all bots. I am trying to speak to BC about the nobots stuff, but I do agree that we should figure out a way that nobots only work for the userspace. User:Zscout370 (Return Fire) 21:18, 9 March 2008 (UTC)
Who exactly are you putting it in a box for? The next logical step, really, would be to deal with it and calm down. As has already been stated to you a half dozen times, he can't be blocked for not complying with something that's optional. So, logically, it doesn't make sense to call for his bot to be blocked. Just to clarify. Sorry it's not in a box, but I didn't feel like coding for it. LaraLove 04:01, 10 March 2008 (UTC)
I'd received two responses basically saying I needed to ask him when I already had. Unfortunately we can't block people for being liars either, I guess. —Locke Coletc 08:24, 10 March 2008 (UTC)

Locke Cole, you've got some good concerns here but might need to tone it down a bit. Like the others have said, this isn't something we can force, but that doesn't mean we can't make these things happen. -- Ned Scott 04:04, 10 March 2008 (UTC)

I'm willing to work with people on this but not if I'm constantly being told to try the same things which I have already tried. It gets old, very fast. —Locke Coletc 08:24, 10 March 2008 (UTC)

Someone quickly make sure BCB doesn't touch Locke Cole's page... <hides in bunker> --Kim Bruning (talk) 19:45, 10 March 2008 (UTC)

Oh boo hoo, you got messages on your talk page. It takes what, an entire minute to delete them? RogueNinjatalk 18:46, 11 March 2008 (UTC)
You know, spammers are particularly fond of that argument. Clayhalliwell (talk) 23:13, 11 March 2008 (UTC)
It's more accurate to compare it to a bill - uploading an image is signing up for a service. Ignore requests to "pay" (checking the FUR) may result in your service being cut off (image deleted). Will (talk) 15:42, 12 March 2008 (UTC)
Wow, why am I even surprised that these kinds of comments are still being made. I asked that he stop posting these messages on my talk page, I followed what is a defacto standard to alert his bot to not leave me messages and the bot continues to do so. Do you get it? Is there something you're not understanding? Don't trivialize things that bother me just because they don't affect you. —Locke Coletc 00:32, 12 March 2008 (UTC) decapitalised and de-bolded by Carcharoth
Heya RogueNinja, Do be nice, eh? --Kim Bruning (talk) 02:15, 12 March 2008 (UTC)
Sorry Locke. But I think its a bit silly to be complaining about easily removed messages, rather than some of the more important issues that have been brought up. RogueNinjatalk 03:21, 12 March 2008 (UTC)
Silly or not, we still get more done here, if we remain civil, and try to make productive comments, instead of mocking, and taunting our fellow wikipedians. That being said, I agree, When you upload an image, you agree to make sure it's compliant with our policies on images (free or nonfree). Should your upload not be compliant, eventually, you will receive a reminder regarding it. And, it's far from easy, oft times, to create an image with a compliant page. I know, even I struggle with that, when I've uploaded images (which, I almost never do, probably why I'm unfamiliar with how to do it right). SQLQuery me! 04:48, 12 March 2008 (UTC)
Thank you. But I do disagree about image responsibility: to turn that argument around, is an editor who introduces a misspelling responsible for fixing it? Would the community react well to a bot that monitored all edits and reported misspellings on the editors talk page (or poor grammar, or any of the other possible problems an editor can have while editing an article)? I really doubt it, and I don't see why we're carving out some exception for image uploaders (who are also contributors of a different sort). It's not like the image uploader is the only possible person who could write a fair use rationale, after all. —Locke Coletc 05:54, 12 March 2008 (UTC)
I can see the point you're trying to make, however, introducing typos, is, at least in my mind fairly different to introducing copyright violations. I also, disagree, about anyone being able to write a fair use rationale, now, for the most part, yes they can. However, finding the source, to satisfy WP:NFCC#10a is not always (even mostly) something that anyone but the uploader can do. Whether or not, that's a silly, unneded part of the policy, is neither here nor there, that's what we have to do, until WP:NFCC is changed. Also, we *do* take action against editors that deliberately introduce copyvios into articles. It's just far easier to detect the vio's in articles than it is in images. Sorry about the possibly incoherent rambling, I'm a tad off tonight. SQLQuery me! 06:18, 12 March 2008 (UTC)
Apples and oranges. If you created an article with a bunch of typos, an editor may try to fix it, otherwise, it would be tagged for deletion, in which case you'd be notified and given a chance to fix it. This is no different than the way we handle images. You created the page by uploading the image. If it qualifies for deletion for any reason, you're the contact, just as you would be as the creator of an article. LaraLove 13:10, 12 March 2008 (UTC)
We don't delete articles simply because they contain typos.. and it's definitely not "apples and oranges". They're both contributions, but you're holding the image contributor to some magically different standard than the person contributing text (this is what is known as a "double standard", FWIW). —Locke Coletc 04:01, 13 March 2008 (UTC)
There is not a double standard. My point was that if you created a mess of an article that qualified for deletion, you'd be notified. When your image doesn't meet policy, it qualifies for deletion and you're notified. That's the point. It's not a "magically" different standard, nor is it a regularly different standard. It's the same standard. Qualifies for deletion, tagged, author/uploader notified. If you don't want the messages, revert them. LaraLove 15:47, 13 March 2008 (UTC)

(unindent) This debate simply must stop -- more and more time is being sucked into it, and it's entirely fruitless. Locke Cole: Regardless of whether you agree with the image policies, they're broader than this wiki and are non-negotiable. While you're correct that typos and such do not qualify an article for deletion, typos aren't a violation of copyright. Typos also haven't been debated for years and had Foundation-level policies written about them. The fact of the matter is this: the image policies are what they are. I guarantee that if you went through your image contributions and found the images that you've uploaded and added fair use rationales, Beta's bot wouldn't be posting to your user talk page nearly as often. If you feel image use policy should change, take it to Meta. Otherwise, let's all move on to writing a free online encyclopedia. --MZMcBride (talk) 04:08, 13 March 2008 (UTC)

Knock it off with the straw mans. This has nothing to do with my view on image policy, this has to do with the harassing messages which are part of a double standard (different "classes" of editors being treated differently). As for your "debate must stop" suggestion, that's not exactly the wiki way last time I checked. I'm not the only editor annoyed by the unwelcome messages which cannot be shut off, I'm just the only one willing to rattle the cage until something is done (and not just for myself, but anyone in the same boat). —Locke Coletc 04:50, 13 March 2008 (UTC)

Locke Cole: are you still getting messages from the bot? --Kim Bruning (talk) 17:19, 13 March 2008 (UTC)

Not so far, no. But I've received no comment or indicator suggesting those messages were shut off. Besides, it's not just about me, there are other editors who also dislike receiving these notifications. See the poll above which has no opposition whatsoever, and which Betacommand is refusing to acknowledge. —Locke Coletc 06:18, 14 March 2008 (UTC)
If you're not receiving any more messages, can we close this case? Other people can speak for themselves, if they also have issues. :-)
Betacommand has no obligation to do anything. The most that you may reasonably ask of him is for him to shut down his bot. This might not be a net gain. --Kim Bruning (talk) 09:38, 15 March 2008 (UTC)
There is no consensus on the proposal. Nor is there consensus to block. --Anticipation of a New Lover's Arrival, The 15:46, 15 March 2008 (UTC)

Confusion?

There seems to be a bit of confusion here. Much of this discussion is about not getting image notifications, but the proposal above wouldn't affect that at all. It specifically states: "This does not address article space, only removal of redlinks/deleted categories from user space, including user page and user talk page." It doesn't seem that everyone is on the same page here... Mr.Z-man 03:11, 16 March 2008 (UTC)

Well, you are in the wrong section, for a start... You want the section titled "Community proposal", not this one, which is titled "Bot needs to be blocked". Carcharoth (talk) 03:18, 16 March 2008 (UTC)
So this is about blocking the bot for not obeying {{nobots}}, the proposal is about making the bot observe {{nobots}}, and the proposal mentioned at least twice in this section is something totally unrelated to the proposal above? Mr.Z-man 03:23, 16 March 2008 (UTC)
That sounds like the right idea. This section is dealing with BCB not obeying NoBots in the User and User talk spaces. The proposal above was started as obeying NoBots in general and became about User/Usertalk. There are other threads here and elsewhere that deal with whether or not redlinked userpage cats should've been/should be, edited by BCB. That would of course hinge on whether or not it respected NoBots, but thats not the main purpose of this thread. MBisanz talk 03:45, 16 March 2008 (UTC)
I think part of the problem is seeing the bot as one thing. Its a collection of scripts that are run independently of each other. If one script observes nobots, that does not mean that the rest will. Mr.Z-man 03:57, 16 March 2008 (UTC)
Arg. I didn't realize there was that point of view, which is valid. I assumed if we were talking about BCB being NoBots compliant within the means of NoBots (exceptions for things like Arb notices, etc), that meant both the redlinks and image notices. MBisanz talk 03:59, 16 March 2008 (UTC)
Well, it would be possible for all or most of the scripts to be made to observe it, but the proposal is only for category removal, which I found somewhat strange given that most of the complaints stem from image warning. Mr.Z-man 04:05, 16 March 2008 (UTC)
Well it was written by AllStarEcho, so he'd know the reasoning behind it best. But since Arbcom has accepted, I'm sure they'll do a better job wordsmithing a binding remedy than any of us can write an ad-hoc proposal. MBisanz talk 04:15, 16 March 2008 (UTC)

Bot needs to be fixed

The real problem is that this is both a buggy program and an unmanaged one. There's no formal change control. There's no Q/A process. There's no regression test suite. There's no release signoff. It's not even clear if there's source control. Yet it performs a key part of Wikipedia's policy process. BetacommandBot is at level 1 of the Capability Maturity Model ("At maturity level 1, processes are usually not documented and change based on the user or event. The organization does not have a stable environment and may not know or understand all of the components that make up the environment.")

That's why we're having all these problems. This is an routine "business software project out of control" situation.

Betacommandbot or its successor needs to be under proper source control, with test and stable releases, bug tracking, and tickets. All those facilities are available on SourceForge, which hosts the MediaWiki software (or at least a copy of an older version). That would at least get us to CMM level 2, "Repeatability", where things mostly work, but may be hard to change. --John Nagle (talk) 03:36, 12 March 2008 (UTC)

As far as I know, Beta is not under exclusive contract with Wikimedia or Wikipedia. ; - ) What I mean by that: if you want versioning and bug reports and all the bells and whistles, build your own bot. Or get a team together to build one (or several). If the new bot(s) function well, they'll be flagged and become the saviors of the wiki®. --MZMcBride (talk) 04:27, 12 March 2008 (UTC)
This BOT is deemed by many as doing a "Mission Critical" task for Wikipedia. It should have some type of quality control process. -- SWTPC6800 (talk) 05:02, 12 March 2008 (UTC)
Pay for it. --Kim Bruning (talk) 09:42, 15 March 2008 (UTC)

Given the shear amount of edits the bot does, and the technical skills BC has, I would wager that the error rate is lower than most other bots. You see more errors because it edits more and because people jump to point them out as soon as they happen. -- Ned Scott 06:18, 12 March 2008 (UTC)

That could be. But we don't know what tasks it's intended to do. The image tagging task, which probably gets most of the unjustified flack, seems to have a low error rate with respect to what it's stated it does (which is not precisely the authorized task, but it's probably as close as a bot can come). Some of the other tasks have a higher error rate and/or are completely unauthorized. (If a bot does exactly what it was intended to do, but it's not authorized, what is the "error" rate?)
A further problem is that, because of its high processing rate, no version of the bot should be run unsupervised. As Betacommand doesn't respond to comments other than the credible threat of a block, if not (in some cases) an actual block, the question of whether he should be considered to be "supervising" the bot is open even if he is actually watching the bot.
A "stop task" button which an admin could "push" would be helpful. A "stop and revert task" button would be more helpful, as can be seen by the latest run of unauthorized category deletions. — Arthur Rubin (talk) 14:38, 12 March 2008 (UTC)
Arthur, the issue with red cats is a content dispute. My personal opinion is remove them. BHG abused her admin powers by using them in a content dispute. there have been other known mistakes that BCBot has caused, and BCBot does not have a function to revert. what I use is Firefox and rollback, with my brower config I can get mass rollback very easy. There was an incident within the last week that was handled without problems. the API was having a fit and decided to just return bad results. this was brought to my attention and I fixed it with very little drama. I am normal watching the bot for the first hour of any given bot run. given the amount of admins who dont understand policy for which they block, I dont trust them enough for that. βcommand 15:06, 12 March 2008 (UTC)
Beta's right, it is a content dispute, and he was acting in good faith when removing the categories. Oh, and last I checked, posting on the bot's talk page will, IIRC, stop the bot. Will (talk) 15:39, 12 March 2008 (UTC)
Will, I had to disable auto shutdown due to abuse of that feature. βcommand 15:55, 12 March 2008 (UTC)
It wasn't a content dispute. It might have been a content dispute if Betacommand would have removed those categories by hand. But he used the bot for that, and as far as I know, it wasn't approved to do that task, and that's what people complained about. --Conti| 15:49, 12 March 2008 (UTC)
Conti, a content dispute is a content dispute. βcommand 15:55, 12 March 2008 (UTC)
The point I'm trying to make is that he thought it was an approved task, and thus removed them in good faith. Will (talk) 15:51, 12 March 2008 (UTC)
Fair enough. I am not doubting Betacommand's good faith here, either. --Conti| 16:04, 12 March 2008 (UTC)
So, at what point did Betacommand believe that removal of (non-CFD) redlinked categories was approved? Where is the discussion that he interprets as approving it? —Random832 17:15, 12 March 2008 (UTC)
I'd really like to point out here that Bot Policy Wikipedia:Bots#Restrictions_on_specific_tasks specifically prohibits Bots from touching certain types of Categories, so I'd say not only was there no apparent approval, but a specific prohibition to doing part of the task. MBisanz talk 17:25, 12 March 2008 (UTC)
MBisanz, you are mistaken, that only states that bots should not populate certin categories. if what BCBot violated that policy, cydebot must have breached that over 50,000 times. what that part of the policy means is that bots should be careful with categorizing people. βcommand 17:41, 12 March 2008 (UTC)

As explained at Wikipedia:Categorization of people, certain types of person categories should not be filled or emptied using a bot.

emphasis added
That seems to me to mean that there are some types of person categories that should not be depopulated by a bot. Unless there is some special filter that I'm unaware of that BCB uses to identity the types of redlinked person categories it should not depopulate, it remains an issue. MBisanz talk 19:33, 12 March 2008 (UTC)
question, what are these special categories? and if BCBot did breach this please provide diffs. otherwise please drop this non-existent breach of policy. βcommand 21:12, 12 March 2008 (UTC)
Person categories are explained in great detail at Wikipedia:Categorization of people. The wording restricting bots from deciding on category assignments for people categories has been in the wording of the Bot policy and Category guideline since September 2004. A sampling of the diffs requested are Foreign Minister cat, Jewish sociologists, Goofus player cat. I'll also note that with Adrian Rollini, you did not revert the removal of the category [1], which I thought was a requirement of the bot unblocking. Even if there were reasons these cats were inappropriate (Misspelling, grammar, etc), I believe the reason the policy restricts general bot changing of assignments is precisly because many of these cases require humans to see the error the bot can't see and fix it manually. MBisanz talk 02:58, 13 March 2008 (UTC)
again per Wikipedia:Categorization of people the only point where it refers to bots is

* Categories should not be automatically assigned: Categories are only assigned as the result of an individual assessment of the content of an article (lists are easier in this sense, because a doubtful assignation can be marked as such). See also Wikipedia:Bots for a general discussion of contra-indications regarding robotized operations.

and that only refers to adding categories. So Im not sure what policy your reading but its not the same one. βcommand 03:03, 13 March 2008 (UTC)
I know, they circular reference each other. WP:Bot Policy-"As explained at Wikipedia:Categorization of people; WP:Categorization of people-"See also Wikipedia:Bots for a general discussion of contra-indications regarding robotized operations." But Policy > Guideline and Policy says bots must be "is useful" and "performs only tasks for which there is consensus". Where is there consensus that bots should edit any people categories or that it is useful to de-cat Jewish sociologists. I'd say the reason Bot policy says "certain types of person categories should not be filled or emptied using a bot" is that Bots should fill categories or empty them based on Wikiproject discussion or WP:CFD, but it would require a human to interpret Foreign Minister means Foreign ministers. As far as I know, there is no brightline policy other than results of a WP:CFD and given the opposition faced for a very similar task at Wikipedia:Bots/Requests_for_approval/BetacommandBot#BetacommandBot_expansion_of_task, it is clearly not "harmless" at face value and therefore required a BRFA. MBisanz talk 03:18, 13 March 2008 (UTC)
  • MBisanz Please stop spreading mis-information, I asked for SPECIFIC policy for what categories bots cannot remove. you cannot provide that. the Only specific reference to bots is about adding. thus all your comments about what cats bots cannot work with was not correct. You were wrong. since you obviously dont carefully read the policy please dont try to enforce policy you dont understand. βcommand 03:39, 13 March 2008 (UTC)
    • I've been under the impression that its up to the Bot owner to prove a function is harmless, not the community to prove why it isn't harmful. If the policy says "certain types of person categories should not be filled or emptied using a bot.", that means there exists some type of category that should not be emptied by bot. If you can't cite a discussion about that phrase showing its invalid or how BCB incorporates this category type differentiation, its operating in violation of the policy. Its the same way your not responsible for fixing the images BCB tags, since its up to the uploader to prove via rationale why they are permissible, you need to show this type differentiation no longer exists (which given the existence of Wikipedia:Categorization of people is difficult to prove) or that this policy restriction is invalid. MBisanz talk 03:54, 13 March 2008 (UTC)
      • MBisanz, I asked you for proof that the bot has violated that part of the policy, PLEASE PROVIDE EXACT POLICY THAT THE BOT VIOLATED AND EXACT DIFFS. otherwise I will take this as unfounded harassment, you stated that the bot violated policy by removing categories involving people, per policy I did not break policy until proven otherwise. If you cannot provide exact proof that the bot violated categorization policy regarding people, I will consider this harassment, unfounded attacks, libel, and an insult. βcommand 04:02, 13 March 2008 (UTC)

Blah. We have a name for nitpicking over policy: wikilawyering. And it's generally frowned upon. That's where the "spirit" of the policies comes into play and we ignore whatever is written on those two pages as of this very moment. Because, this is a wiki after all, and almost anyone is free to change those pages -- and those changes may or may not be reverted, depending on who's paying attention.

So... as to the matter at hand, Beta removed red-linked categories from a series of pages. When it became clear that this was controversial / unwanted by other editors, he stopped. A discussion isn't required for every action that an editor takes (even a bot). Good ol' common sense can surely suffice. And, it's important to assume the presence of a belly button. You live, you learn, you revert -- it's time to move on. --MZMcBride (talk) 03:58, 13 March 2008 (UTC)

That's where you're wrong AFAIK: bot actions must be discussed before being done. Or is WP:BAG just a tree house club? —Locke Coletc 04:52, 13 March 2008 (UTC)
MZMcBride, you aren't telling the full story there. Betacommand was asked several times to stop his bot removing those redlinked categories before he eventually did stop. And he didn't revert until much later, after some manual reversion had been taking place. In Betacommand's defence, I will note that he did later, on his own account, do lots of category spelling corrections (and decapitalisations) from a list that someone else provided (User:Random832 I think). But working with others and discussing things right from the very start would have avoided that. And I still don't understand why he said he has done this work in the past - as far as I know, he still hasn't linked to any contributions demonstrating this. I'd like to check whether previous runs made similar mistakes, but the sheer size of BetacommandBot's contribs list makes this difficult. Carcharoth (talk) 21:48, 13 March 2008 (UTC)
Also, Betacommand said above "Arthur, the issue with red cats is a content dispute. My personal opinion is remove them." - that is fair enough, but to remove them by bot Betacommand needs: (1) community consensus that such removals are needed (and he has never and never will get that consensus); and (2) a successful bot approval request. I've looked at Wikipedia:Bots/Requests for approval/BetacommandBot, and nowhere there does it say that removing redlinked categories (that is, categories with tags on articles but where the categories have never been created or deleted) is part of the approved tasks. The only approved tasks relate to those where CfD has done stuff, and Cydebot does that already, so not only is what he did off-task, even the on-task stuff is not needed. Carcharoth (talk) 22:04, 13 March 2008 (UTC)
When I get time and access I will send the two hours or so filtering BCBots 880,000+ edits to prove that I am correct something MBisanz has yet to even point to policy let a lone diffs. βcommand 22:09, 13 March 2008 (UTC)
here is one previous red cat run. βcommand 05:16, 14 March 2008 (UTC)


If you had kept careful records of each run you did with your bot, you wouldn't need to do this filtering. But since you seem prepared to do this filtering, would you be able to make a permanent on-wiki record of what edits relate to which task. Don't worry about having a miscellaneous list for the, um, shall we call them "not-quite-authorised test edits"? If that is too much, could you at least filter out the edits that don't relate to non-free image work? Carcharoth (talk) 22:34, 13 March 2008 (UTC)
I've shown diffs of people categories that shouldn't be removed. I'm in the process of researching the certain types criteria. Its starting to look like the criteria weren't directly linked at the time that policy phrase was formatted and are stuck in some other page. Given its 3 years old, its taking awhile to nail down diffs and what not, but it does seem it was added with the reason that Bots should decide on categories of people in a broad sense of certain types being non-CFD'd people categories. MBisanz talk 00:47, 14 March 2008 (UTC)
I would like quotes from the current policies stating exactly what types of categories bots should not touch. I doubt you can find that because I doesnt exist. βcommand 2 00:57, 14 March 2008 (UTC)
PS. Have you seen the section by AKAF at the RfArb? This bit was particularly interesting: "I think that Betacommand's refusal to provide the source to Betacommandbot (except for the single task (of 11 approved) noted by Lar above), is rooted in the fact that "Betacommandbot" mostly consists of throw-away simple scripts which remain untested and probably mostly no longer exist. Betacommand's insistence to the contrary, it seems unlikely that such disparate tasks actually require a monolithic code." - I'd actually be interested in seeing an on-wiki response by you to that - it is an interesting point that I haven't seen raised before - is BetacommandBot really a bot? Carcharoth (talk) 22:34, 13 March 2008 (UTC)
there is no real way to post data you want, BCBot has over 100,000 edits not related to NFC rationale tagging. I was plannig on running some possible filters (toolserv database queries) to find one example and link to that secton of contribs. As for asking if BCBot is really a bot, please define what you mean by a bot. βcommand 22:44, 13 March 2008 (UTC)
Something where you need approval, that you couldn't just run using a script. 100,000 edits is only 20 pages of 5000 edits each. That is not that large an amount. Carcharoth (talk) 22:55, 13 March 2008 (UTC)
Other than the accidental AWB, or forgetting to logout, its all scripts. there have been accidents where BCBot has run on my account also. (forgot to change pywiki user-configs) βcommand 23:12, 13 March 2008 (UTC)
  • Just for the record, BC is editing as BC2 in this thread, if anyone's ever needing to find these contribs. Isn't this one of the issues being discussed at the RFAR? The use of both accounts interchangeably, to the understandable confusion of many? Bellwether BC 00:16, 14 March 2008 (UTC)
    • Im sorry but I prefer for security, and other reasons not to use my main account on public computers. βcommand 00:21, 14 March 2008 (UTC)
  • Then why not change the sig on BC2 to something distinctive to that account, to avoid the natural confusion caused by the use of the alt account at such times? Bellwether BC 00:24, 14 March 2008 (UTC)
  • this was the first time I was asked, Ive changed it, does this help? βcommand 2 00:48, 14 March 2008 (UTC)
  • If I can add that I don't find it overly burdensome that BC uses 2 accounts. Changing the sig to include the 2 is helpful, but I've seen other active users spread their edits over several accounts over time and it doesn't seem to be a huge problem. Now if BC2 was being used as a bad-hand account or if the link between them wasn't obvious then I'd have a problem. MBisanz talk 00:53, 14 March 2008 (UTC)
  • I tried to make it as obvious as possible. βcommand 2 00:59, 14 March 2008 (UTC)
  • I have to say, until you said that, I'd never noticed the tiny little "2" after it. It looks identical otherwise. I was thinking more about a different color for BC2, or something that would make it clear "I'm on my alt-account now." Bellwether BC 01:03, 14 March 2008 (UTC)
The 2 is new since you asked him to make it identifiable in his sig. Avruch T 01:04, 14 March 2008 (UTC)
  • (edit conflict) Okay, I feel like an idiot. You just added it, is why I'd never noticed it. Anyways, the only issue I see is that with the issues that have come up, using two accounts indistinguishable by sig can make it difficult to find diffs if needed. A change of color or something like that would probably be the most helpful thing, but the tiny "2" is better than nothing. Bellwether BC 01:06, 14 March 2008 (UTC)
Regarding Betacommand2 and alternative accounts, I would still be happier if Betacommand could take just a few second to update User:Betacommand2 to say (as he does above): "I prefer for security, and other reasons not to use my main account on public computers." Otherwise people are just going to get confused by what it says there at the moment: "this is my Test & VandalProof account" (which dates from July/August 2006). I know, no-one really objected before, but would 'please' help? Carcharoth (talk) 08:16, 14 March 2008 (UTC)

How can a BCbot task be rescinded?

I was pleased to see Caracaroth's note in the previous thread that BCbot is not needed for CFD work, because CydeBot already performs that task. I had made that point before, and I noted that Cydebot does a much better job, with edit summaries which make it very clear which CfD decision is being implemented in each edit.

BC has also had diffivcult in accepting the narrow limits of the task, and is still arguing here that it is for objectors to prove that he violated policy, rather than accepting that a task should not be run without both community consenus and technical approval from BAG. He is compounding the trouble by arguing that the removal of the redlinked cats was a "content dispute"[2].

This "content dispute" claim is the most worrying statement I have seen on the matter, because if anyone who objects to a bot performing what is believed to be an unauthorised task is deemed to be party to a content dispute, then there is no way of stopping the bot: every admin who takes a view on the matter becomes automatically involved. I have raised this point in my submission to arbcom, because to me it indicates a bot which is simply out-of-control.

I hope that arbcom will accept the case, but in the meantime I see no need for BCbot to be doing any work on categories. Given the gap between BAG's approval of a bot for specific tasks and BC's insistence that it is not up to him to demonstrate that the task is authorised and his consensus, I would like to see the matter cleared up by the removal of any authorisation for BCBot to do any category-related work.

I know that some editors will disagree with me on this, but please leave that aside for now. The point which concerns me is how a bot's approval can be challenged? BAG members have repeatedly said here that they regard their task as purely technical. Is there any mechanism by which a bot's approval for a task can be challenged without arbcom taking up the case? --BrownHairedGirl (talk) • (contribs) 01:56, 14 March 2008 (UTC)

Having discussed this with WJBscribe, this is one of those very very gray areas. BC mentioned once that WT:BRFA. But to me that still seems like a BAG-area, not a community forum. I created the Wikipedia:Requests_for_comment/User_conduct#Use_of_bot_privileges, which I hoped would resolve this gray area. But not enough input into my decision has occured for this to be considered a binding process. So..., I'm not sure. MBisanz talk 02:09, 14 March 2008 (UTC)
Thanks for your reply. Some of my concerns are matters which I think BAG should be considering, so I will try there. Your RfC process sounds like a good idea, and I made try that too, but first of all I will be interested to see whether BAG is prepared to examine the issues. If BAG is not prepared to review bots which it has authorised, then we have a big structural problem; I hope that it will look at this. --BrownHairedGirl (talk) • (contribs) 02:25, 14 March 2008 (UTC)
Without commenting on BCBot in specific, I agree, that there should be a general process to de-approve bots. The RfC method sounds workable to me. It may be possible to run a 'reverse BRFA' as well. That may well be the most appropriate forum. I'd be interested to see what others think. SQLQuery me! 04:26, 14 March 2008 (UTC)
Ok, Cydebot does not do all CfD. Cyde has refused to touch user cats. I said your block was a content dispute and stand by that. Ryan's on the other hand can be considered blocking for an un-approved task. What you did was abuse your admin tools in order to force a user that you were in dispute with to follow your POV. yes the task might have been un-approved, but the re-addition of thousands of point-less red-links is a content issue. Had this been a case where BCBot miss-tagged images there would have been zero issue with me reverting. But this was a content dispute. If you have questions/issues please raise them in a calm, civil, respectful manner on my talkpage. I am always willing to work with those kinds of people. As I have always said Please take issues calmly and respectfully to my talkpage and nine times out of ten you will have a positive result. I am less inclined to work with the drama creating users who insist on not posting on my talkpage but instead posting to AN or ANI just for the sake of drama. I dont like drama, never have never will. βcommand 03:59, 14 March 2008 (UTC)
"the re-addition of thousands of point-less red-links" - many of those redlinks are NOT POINTLESS. Sorry for shouting, but you just don't seem to get it. I'm surprised at this because you have been doing manual script work on your main account correcting red-linked categories with spelling mistakes and turning the redlinked categories blue (for example, here). This is great work (I think you are using a list supplied by others), but it puzzles me how you can do that on the one hand, and then turn around and still seem to be claiming that all red-linked categories are "pointless". Regarding the user categories comment (which you mentioned in relation to Cyde not touching them), I am beginning to suspect that you started working in this area in order to enforce the recent removal of redlinked categories from user pages. I know that is one reason Allstarecho would strongly object to you ignoring the nobots tag and removing certain user categories from his user page. If this is (mostly) about user page categories, then please don't mix that up with article categories. There is probably a reason Cyde refuses to touch them. I suggest you try and separate the two sorts of work and not mix them up. Carcharoth (talk) 08:23, 14 March 2008 (UTC)
Carcharoth, you are off by a mile, by removing the red links, either by fixing the issue, or just plain removing them. I solve the issue. Users notice the removals and address the issue properly, they either agree with the category removal or fix the issue with the category. what we dont have is thousands of basically useless red cats. As for user categories, VegaDark approached me to give assistance with WP:CFD/UW. instead of assuming things with out basing them on facts is a bad idea. There were technical reasons for cyde to not work with user cats. I dont care to go into exact details. but cyde prefers not to work with them due to the nature of how userpages are formatted. As I know from previous experience removing red cats it motivates people and improves the encyclopedia. βcommand 08:42, 14 March 2008 (UTC)
The technical reasons being that user categories often come from templates such as userboxes? Look, if you explained more things upfront, and were more responsive to initial questioning (you are responding now, I admit), then people wouldn't have to speculate and assume so many things. Communication. Communication. Communication. And no, IRC does not count here. I agree that redlinked categories are a large area of links that needed examination, and that they were overwhelming that Special:Wantedcategories page, but just the smallest amount of on-wiki discussion with people who work with categories would have immensely improved the results you obtained. It is crystal-clear that correcting capitalisation and spelling mistakes is a vast improvement on "just plain removing them" and hoping that "Users notice the removals and address the issue properly". You are, in my opinion, over-estimating the chances that users will notice things and correct them. This also varies with namespace and the user. Correcting a category on the page of a user who hasn't edited in years obviously isn't as needed as correcting a category on the page of an obscure article, or indeed a well-watched article. In addition, if people see the edit summary "CfD work", then they may not even bother to fix the problem (they may assume that the category was deleted at CfD). There, I think I've dismantled your entire response, and I have yet to see any evidence from you that this statement has any substance:"As I know from previous experience removing red cats it motivates people and improves the encyclopedia." Please, if you are going to post sweeping statements like that, take the time to do the filtering you said you were going to do, and find this previous work. That way people who want to can actually follow-up and see how often such redlink category removals were followed by a user correcting the removal by adding in the correct spelling/capitalisation. You've been asking MBisanz to provide diffs. It's time for you to do the same. Carcharoth (talk) 08:55, 14 March 2008 (UTC)
OK. I just noticed this edit further up the page. I hadn't noticed that, thanks. I've now asked for that run to be reviewed. While that is being done, could you please answer the other questions in my post above. Carcharoth (talk) 09:01, 14 March 2008 (UTC)
User talk:Betacommand/20060906#BetacommandBot & rivers of somerset is one example on how removing a red link improves things. Ive seen some of the links BCBot removed, and then was forced to revert, were again removed my users. (I dont have a diff handy). Im making my statements not from general guesses but rather I have seen what happens after a removal run. βcommand 09:09, 14 March 2008 (UTC)

The more I look at this, the worse it gets :(

  • Betacommand still believes that requiring his bot to follow WP:BOT and revert unauthorised tasks is a "content dispute". As above, that logic makes it impossible for anyone to require him to revert, because as soon as they object, he can label them as an involved party. The fundamental problem here is that BC does not appear to have read WP:BOT, which stresses that with a bot or any other form of mass-editing, consensus should be sought before the work is done, not afterwards: "Contributors intending to make a large number of assisted edits are advised to first ensure that there is a clear consensus that such edits are desired."
  • As to WP:CFDU, it is unclear whether BCbot is authorised for that task: the authorisation is only for WP:CFD. If BCbot is going to do implement WP:CFDU/W, then for clarity it should seek specific authorisation for that task. I suggest that if BCbot is to do WP:CFDU/W implementation, then it would be better for BCbot to be authorised for WP:CFDU/W but not for other WP:CFD work, which is performed to a high standard by Cydebot.
  • The arguments which Betacommand makes in favour of removal of redlink categories do not belong here: they belong at WP:BRFA. However, he still doesn't get it: of course some redlinked cats are nonsense and should have been removed. As has been repeatedly pointed out, the problem was the bot was indiscriminate and removed not just nonsense cats but those with typos, capitalisation errors and other small errors (such as the example I first drew to his attention of Category:Conservative MPs which should have been Category:Conservative MPs (UK)). Other, such as this edit (from the 2006 run) removed Category:Sheffield Steelers players, which was created a few months later. After this much time, it's hard to know what the situation was then, but it may have fallen into a further case of redlinked category, where an editor adds a valid the category label to articles but does not create the category, and in such cases the appropriate response may be to create the categ. The common issue with redlinked categs is that some human judgement is required, which the bot did not make.
  • The list from 2006 also reveals a further problem of inadequate edit summaries. No reason is given for why the categories have been removed, and the categories are not linked, which makes it harder for editors to trace the history of the removed category. For example this edit has a summary of "Removing from Category:Serialised novels" ... which is thoroughly uninformative. If the bot had been authorised for this work, the edit summary should have been "Removing from non-existent Category:Serialised novels". The redlink-removal run which led to Ryan's block did link the category names, but included no reason for the removal; that sort of lazy edit summary frustrating enough when it is done manually by an editor, but when it is done across thousands of edits by a bot, it becomes highly disruptive, by leaving thousands of editors to try to guess why the bot did what it did. --BrownHairedGirl (talk) • (contribs) 13:23, 14 March 2008 (UTC)

Analysing previous bot run on categories

Betacommand has kindly provided this contribs log for a previous bot run from September 2006. Could someone please analyse this? If there are problems, I intend to ask Betacommand or others to find all the category work done by this bot so it can be reviewed properly. Carcharoth (talk) 09:04, 14 March 2008 (UTC)

I dunno about analysis but to pick a random entry (2nd one I looked at), 07:49, 29 September 2006, Blood Ritual (album), the "second LP...metal group Samael" - edit summary is "Removing from Category:Samael albums". I don't see any deletions in the log for Category:Samael albums, though I could be wrong.
Analysis could be quite difficult. What was the rationale for this bot run? What rules was it performing? Where did it log the rule step that triggered its edit?
Ah, maybe I see it now! LP vs. album - have to know about those pesky vinyl records. Would "CD" fail the rule as well? Franamax (talk) 09:31, 14 March 2008 (UTC)
Given that I can't figure out how to check the existence/deletion of categories, I'll re-emphasize my "could be wrong" statement above.
The fifth random check is 07:38, 29 September 2006, Heimerad, "Saint Heimerad (also known as Heimrad)..." - edit summary is "Removing from Category:Saint" which rather ignores the human-spottable correction. The article about this saint remains outside the Saints category (and doesn't give verifiable details of his beatification or sanctification, but I doubt the bot is Catholic). This one looks to be a simple language/syntax issue, effortless for humans, extremely hard for a computer (I'd try [$catname|$catname{s}] or something like it to catch this simple case). It also demolishes my word matching speculation above (album vs. LP) and makes it essential to know the details of the intended task and state-of-wiki at the time.
I'll stop now, we might need a little more definition. The Saint/Saints example is demonstrative of the perils of machine execution. Franamax (talk) 10:39, 14 March 2008 (UTC)
To see if a category was deleted, click on the redlink and you should get either a "does not exist, do you want to create it?" page (in which case it was never created or deleted), or a log detailing when the category was deleted. Any deletion log should link to a CfD discussion, or give a 'speedy deletion' rationale. If that fails, click on "what links here" to see where the category deletion was discussed, if anywhere. Carcharoth (talk) 10:49, 14 March 2008 (UTC)
Duhh, I set my own wiki up so I could figure this stuff out without asking! (I'm gonna block that Franamax on my localhost, he's disruptive). On review then:
  • Blood Ritual (album) - category did not exist on 29Sep06. Category was created 31Oct07 by a remarkably prolific editor presumably using a script, although there are no edit summaries to illuminate this. The bot probably operated correctly to its definition, the alternative would be for the bot to have recognized an uncreated category with more than one member and created it, or left the redlink alone.
  • Category Saint vs. Saints stands as a human-definable "error", still uncorrected. Why did the bot examine this article, based on what rule?
As noted above, the key to analysis is the definition of the specific bot task for the run, the article/category list, the specific regex rules used, and the rule triggers that enabled the edit. If the task was "IF category-not-exist THEN delete-category-redlink FOR all-articles", you can probably be quite sure it executed correctly. If the task was "FOR ALL members-of-redlink-cat, DO delete-category-redlink", that probably ran properly also. What was the task? Franamax (talk) 12:30, 14 March 2008 (UTC)
The bot almost certainly ran correctly in technical terms. The issue here is whether it should have done this at all (whether the task was approved). There is no consensus or approval to use a bot to do this type of work. The "left the redlink alone" would have been the proper action. Just because an editor added a category tag, doesn't mean a bot can removed it unless specifically instructed to do so by WP:CfD (this follows from general bot policy). For Blood Ritual (album), the article was created at , the category in question (Category:Samael albums, created 31 October 2007) was added on 1 December 2005. In other words, it was a red-link from then until BetacommandBot removed it on 29 September 2006. The category was restored with this edit (changing from a more general category to this more specific one) on 31 October 2007, as you note by the same editor who created this and other categories. Regardless of the merits of the category, BetacommandBot's edits here do not appear to have helped in any way whatsoever, and as MBisanz has noted at the request for arbitration, may have been actively harmful. Carcharoth (talk) 13:04, 14 March 2008 (UTC)
I certainly don't see where removing the Saint category as part of a high-speed edit run is a positive contribution, when changing the category to Saints would be so much more constructive. Removing a redlink death-metal category for a year until someone decides anew that it should be added in blue doesn't seem especially helpful either - unless this was sanctioned somewhere. Did that happen somewhere we haven't found yet? Franamax (talk) 13:20, 14 March 2008 (UTC)
"Did that happen somewhere we haven't found yet?" - I doubt it, though I will be the first to apologise to Betacommand if he can find a discussion about this. I think we have enough evidence here to ask WP:BAG to issue Betacommand a formal warning about this sort of behaviour with his bot and an instruction to submit all the category-related edits by his bot for review. If WP:BAG won't do that, then it's back to ArbCom. In case anyone tries to claim this is related to the non-free image criticisms, I still in principle support Betacommand's work in that area, but I also do category work and I find BetacommandBot's edits in category-related areas even more troubling than the bot operator's incivility related to non-free image work. Actual article navigation and development of the category system has been disrupted. Carcharoth (talk) 13:35, 14 March 2008 (UTC)
Well considering his plan to tag all empty cats was rejected by BAG, I doubt there is some secret approval page for the redlinked issue. If there is an RFAR 2, I'll probably draft an expanded version of the my additional statement offline. Although, I wonder if ARBCOM would like it better if it came from a user-conduct RfC focused on this catting issue... MBisanz talk 13:43, 14 March 2008 (UTC)
Has BC yet provided a complete breakdown of BCB's edits by task so we can verify the ops? I'm not sure whether there's been previous mention of non-standard tasks (possibly user-talk spamming) and my bed is much closer than wiki right now. Franamax (talk) 13:48, 14 March 2008 (UTC)


I have a bot myself, BHGbot. Before any bot run, I assign a job number, and create a page describing the task, and then proactively seek input before I start. BHGBot's jobs are wikiproject-related, so I seek input from the relevant projects, and only start work when a consensus is established. As one example, see User:BHGbot/Job0007; discussion at Wikipedia talk:WikiProject Ireland/Assessment#BHGbot_stub_tagging and at User talk:BHGbot/Job0007, and each edit tagged with the job number (see this example). Everything is documented, so that anyone encountering an edit has a direct link to an explanation of the job's scope and purpose and to evidence that consensus was sought. Sure, sometimes discussion in advance will miss a problem and a job will still cause unforeseen problems or need to be stopped ... but the small amount of extra effort required in doing it this way is not a big overhead when set against a few thousand edits, and it potentially saves a lot of time for all the hundreds of editors who see the edits in their watchlists.

Sometimes this seek-consensus-in-advance approach means that a relatively innocuous job which I think is a good idea doesn't get done: see for example User:BHGbot/Job0005. No responses on te talk page, and no responses at Wikipedia talk:WikiProject_Northern_Ireland#Bot-driven_tagging_of_Northern_Irish_categories, so the job didn't happen. I don't believe that WP:BOLD applies to a bot, so this job will not happen unless and until I have established "that there is a clear consensus that such edits are desired". Why does Betacommand not adopt a similar approach, per WP:BOT? --BrownHairedGirl (talk) • (contribs) 13:53, 14 March 2008 (UTC)

Do you get your bot tasks approved by BAG? When you seek a consensus ahead of time, is one person agreeing typically regarded as consensus for your bot's tasks? Avruch T 17:09, 14 March 2008 (UTC)
Like other bots, my bot has approval from BAG for its limited range of tasks. What I was discussing above was the jobs done under those tasks.
What constitutes consensus is not always easy to gauge, but what I have done is to advertise the job at the relevant wikiprojects and look for input from those regularly participating. My main interest is not in counting "yes" votes, but in ensuring that adequate notice is given and that any objections or concerns can raised before the bot starts work. In some cases that has meant that the task list is trimmed, and in other there has not been any feedback at all, so the job has not proceeded.
I don't claim that my procedure is perfect, but it has ensured that other editors have an opportunity to comment. WP:IE has few active participants at the moment, so there has been less feedback than I would like, and I would welcome suggestions on how to improve that. --BrownHairedGirl (talk) • (contribs) 02:53, 15 March 2008 (UTC)
  • One problem is that it is often difficult to gain consensus on some of BCBot's jobs, even though they are required to conform with policy, as can be seen by the existence of this subpage of ANI. Unfortunately, BCBot's image work has to happen, regardless of even significant opposition. On other work, I agree with you.Black Kite 13:58, 14 March 2008 (UTC)
    • I quite agree that seeking prior consensus on NFCC work would probably just create migraines on a large scale, and that those jobs should not be put out for individual feedback in advance: as you say, the work has to be done. However, I don't see why they can't be documented and numbered.
      AS to existence of this page, if it existed only because of NFCC work, we probably wouldn't have an RfAR open at the moment. There are many problems reported here relating to BCbot's other work, such as the redlinked categs, the inadequate edit summaries, and the use of the bot to attack MickMacNee (whose conduct may well have merited sanction, but attack by a bot is not an appropriate response). --BrownHairedGirl (talk) • (contribs) 14:22, 14 March 2008 (UTC)
  • you cant call sending MMN 50 image notices an attack, at worst it was a Minor violation of WP:POINT in response to his constant trolling. here is a list of all BCBot edits that are not related to NFCC image tagging. WARNING that text file is ~75Mb uncompressed (187,496 edits), If you have current questions about BCBot please take them to my talkpage. βcommand 15:20, 14 March 2008 (UTC)
  • Bellwether, based on what you said at WT:RFARB, I think your "wow" is directed at Betacommand's MMN comment. There have been enough comments about that already to show that Betacommand is just wrong here (the consensus seems to be that the spamming was totally unacceptable and that MMN wasn't trolling, though he was a bit aggressive at some points). My advice is not to worry too much about it, but let's keep working with Betacommand. Carcharoth (talk) 15:51, 14 March 2008 (UTC)
  • I respect you greatly, Carch, but I find it nigh impossible to work with an editor that refers to good-faithed criticism as "trolling" and then calls his own trolling a "minor violation." However, I'll back off from this page, and let you work with him, since I'm getting to a point that his behavior towards others is so distasteful to me that I find it difficult to maintain a modicum of civility with him. (Thus, the succinct "wow" in the previous post.) Bellwether BC 17:14, 14 March 2008 (UTC)
  • Thanks for that file Betacommand. I'll definitely look at that at some point and play around with it and see what I can come up with in terms of reviewing some of the past edits or splitting them up by task or edit summary. I don't mind doing that if you don't have the time. Carcharoth (talk) 15:51, 14 March 2008 (UTC)
  • For anyone interested, I have Beta's edit file loaded into an Access DB file and split into three Excel spreadsheets. Drop me a mail for a copy. I assume that BC has no objections to his data being redistributed in different formats? Franamax (talk) 20:48, 14 March 2008 (UTC)

What's the total number of edits? I think I see why people might have issues with Betacommandbot. With the sheer number of edits it looks like it's making, pure statistics alone would suggest that someone is going to be angered somewhere. I guess that's organizational friction for you. ^^;;

The amazing thing is that it's still being tolerated. It must have been written very well! :-) --Kim Bruning (talk) 09:50, 15 March 2008 (UTC)

The total number of edits is only a problem because several different tasks have been mixed up together. Very specific problems with category work have been raised here, so a generalised comment about "statistics alone" doesn't really help, Kim. Going back to the number of edits, it should, in theory, be relatively simple to say "do you have a list of all the edits the bot made for this task". Because it is programmed behaviour, not human behaviour, keeping track of what a bot does is easy if you use the right edit summaries and document what you have been doing. This means that when problems arise (even if it is years later) you can go back and review the edits. Moving on to your "don't push too hard or he might shut the bot down" comments in the 'nobots' thread, I don't actually think any of BetacommandBot's functions couldn't be done by another bot - we've had bot operators and bots leave before, and usually someone else eventually takes up the slack. Over-reliance on any one bot or operator is never good for Wikipedia. Betacommand does an awful lot of good work, but he needs to be more communicative on-wiki (I get the impression he discusses things a lot off-wiki) and able to take the genuine criticism along with the praise (and respond to that criticism and work with others to improve how he and his bot does things), and recognise the unfounded complaints and either respond politely or let others deal with that. Merely saying "let's cut the guy some slack" doesn't work when he doesn't do the same. He does eventually work with people on-wiki, and answer difficult questions, but it is genuinely hard to make progress sometimes. With most users, that is not too much of a problem, but with a bot operator running a bot that makes tens of thousands of edits (to be precise over 900,000), this is a problem. Carcharoth (talk) 10:31, 15 March 2008 (UTC)
Hmmm. --Kim Bruning (talk) 10:58, 15 March 2008 (UTC)
What sort of hmm is that? I'm not a mind reader. Carcharoth (talk) 11:03, 15 March 2008 (UTC)
Even if you were, it wouldn't help you much ;-) It's the "I'm still mulling this over" kind of Hmmm... :-) --Kim Bruning (talk) 11:07, 15 March 2008 (UTC)
Well, I corrected a does -> Doesn't in my post, if that helps. :-) Carcharoth (talk) 11:52, 15 March 2008 (UTC)
Ok, after pondering a bit, here's my first question I guess:
Are you saying that you wouldn't mind if BCbot was discontinued?
--Kim Bruning (talk) 00:27, 16 March 2008 (UTC)
I don't think I am saying that. I support the good work Betacommand does, including the non-free image work and other bot work. What I don't support is the way Betacommand does things: (1) bundling of tasks into one bot; (2) incivility and over-reaction; (3) a cadre of supporters who uncritically defend him (to be fair, Betacommand can't do much about that); (4) issues with WP:BAG; (5) a general tendency for minimal communication; (6) running tasks with insufficient input from the relevant areas of the community; (6) overstepping or misunderstanding the bounds of his bot tasks. I may have missed a few points. None of these are exclusive to Betacommand, but taken together in one bot operator, the problems become noticeable. I have seen the co-operative side of Betacommand as well, so I know it is possible. I think what he really needs is someone or some people to act as a buffer between him and others. Either that, or give up the non-free image work and concentrate on other areas. Carcharoth (talk) 01:00, 16 March 2008 (UTC)

BetacommandBot bug - misparsing backlinks

I just noticed an edit [3] in which BetacommandBot incorrectly tagged an image which already had a valid "Non-free / fair use media rationale". The bug, I suspect, is that BetacommandBot doesn't correctly parse links with underscores. The Wikimedia system considers "Protestant_belief" and "Protestant belief" to be the same article, but BetacommandBot's parsing is apparently inconsistent with the Wiki code. --John Nagle (talk) 03:40, 16 March 2008 (UTC)

Yes, that appears to be a bug, but I doubt it has anything to do with the underscores or some other quirk in the regex matching. The page had been updated a few hours before; it's possible the bot was working with old data. It's also remotely possible the image was used on some other article at the time. But if you think BCB mishandles underscores, test your hypothesis by watchlisting this or some other image to see if anything happens. Gimmetrow 04:05, 16 March 2008 (UTC)
Blindly running off of old data would be a bug, and a serious one. A read only sweep may turn up pages of interest in advance, but the actual edit requires a page recheck. As with human users, you read the page and get an edit token, then write the page. If there's an edit conflict, the update fails. There's proper transaction integrity. Incidentally, the MediaWiki API people have finally finished the "Edit" function, although it's not enabled for Wikipedia yet. That's the right way to do future 'bot work. --John Nagle (talk) 04:47, 16 March 2008 (UTC)
I don't think using old data is the case. Could have been anything, an API quirk (the API was acting up the day before), maybe it was something with the underscores (but I doubt it). We would all just be speculating. Beta is pretty good at picking out what made it fail. I know his talk page is being flooded right now, but this should probably be posted there (I am not sure AN/B is the proper venue for a single error). - AWeenieMan (talk) 05:07, 16 March 2008 (UTC)
FYI, the bot runs in "batches", so it has a lag built-in. I discussed that with Beta some time ago, and he said he changed some things so the lag is normally under 10 minutes. But I notice there were large intervals separating each edit about that time, so it's possible the servers were preventing the edits and so preventing a data refresh for the next batch. If it were data lag, it's been over a week now so the image would pass. Gimmetrow 05:16, 16 March 2008 (UTC)
Ahh. That does make sense. Yes, I would have assumed there was some lag (the term "old data" made me think something a little more grand and problematic). - AWeenieMan (talk) 05:29, 16 March 2008 (UTC)

Not strictly the same thing, but I've been working on Wikipedia:WikiProject Academic Journals/Images and I noticed that one of the images there didn't get tagged. For example, Image:Eighteenth-century studies.gif passes his tool. I was wondering if there was a reason for this and whether Betacommand will be doing anything about this? If there are a lot more images out there that might be tagged, the claims that the tagging is "over" might need to be re-evaluated. Carcharoth (talk) 08:40, 16 March 2008 (UTC)

This is why it would be benificial and in Betacommand's own interest if we knew what the code that parses the image page code looks like. As for the lag issue why isn't the bot checking the timestamp of the last known edit before it evaluates the image page? I can understand why Betacommand would want to do things the way he does but checking this is a simple API query before the bot tags the image (or decides to ignore it). I know Betacommand wants to keep the code simple and there are certainly advantages to doing that but a) this isn't complicated to begin with and b) safety checks aren't in violation of the keep it simple principle. If Betacommand would allow more people to work on the code this wouldn't be difficult to do. EconomicsGuy (talk) 09:40, 16 March 2008 (UTC)
The two comments below were refactored and were not in this location originally, and the comments after were replies to EconomicsGuy and not these statements.
I notice the image name for Image:Eighteenth-century studies.gif matches the article that includes it, modulo case and underscores. Is that sufficient to keep βCBot at bay? —johndburger 14:56, 16 March 2008 (UTC)
I don't think so. It tagged this one, where the title matches the image name. Carcharoth (talk) 21:42, 16 March 2008 (UTC)
My sense is Beta designed the code to maximize edit rate, a fairly important consideration given the number of images. He may have designed some form of threading where data lag is a consequence. Gimmetrow 23:27, 16 March 2008 (UTC)
If so, there's a serious locking problem in the code. The interface to Wikipedia requires that you read a page, get an edit token, then replace the page using the same edit token. It's hard to get a time-of-check/time-of-use bug with that interface, although you may get a token rejection on the write, which is what an edit conflict looks like to a 'bot. I'm starting to suspect that the main reason the code isn't released is that it may be embarrassingly bad. --John Nagle (talk) 00:45, 17 March 2008 (UTC)
I know the bot is using threading because that's the only way I've been able to reproduce the speed Betacommand says his bot can edit at. If the bot is doing this in two stages, one to get a list of images to tag and one to actually tag them the bot needs to do a sanity check before it attempts to edit the page even if it is getting the edit token correctly. With the current way that works though I don't quite see the advantage of doing this in two stages because to get the edit token it still needs to fetch the entire page including the image page text so it may as well do this in one stage rather than two. Would be easier on the servers anyway until the edit api is enabled. It does depend on how the threading is implemented though because if he is doing this by having one thread check the page and another actually edit the page he is pretty sure to get into an edit conflict sooner or later, at least without sanity checking. The truth is we really don't know until we see the code, it may be a major design error or a simple bug caused by lack of a simple api query. If more people were allowed to work on the code we could move forward with this rather than having to guess about what the code looks like. EconomicsGuy (talk) 02:13, 17 March 2008 (UTC)
And I know the bot is using threading because Betacommand said so! :-) See Wikipedia:Administrators' noticeboard/Betacommand/Archive 2#Questions, where computer threading (and its limitations) were discussed in the context of leaving talk page notices. Carcharoth (talk) 02:49, 17 March 2008 (UTC)
Correct me if I'm wrong here but is he saying his trying to get the threads to work on the same object? If so, the bot is badly constructed to begin with. Two threads shouldn't be trying to work on the same object at once and no "hack" will solve that issue. Why isn't the bot collecting the warning messages and inserting them on the talk pages in one edit? Have the bot tag the images and then edit the talk pages in a more appropriate and from a programming point of view more safe way. This would also greatly reduce the required speed at which the bot needs to edit. Bot needs a rewrite if this is what is going on. EconomicsGuy (talk) 03:41, 17 March 2008 (UTC)
After reading that description, it does sound like the program has some concurrency problems. It's straightforward to make coordinated multithreaded programs work in Python. In fact, it's easier in Python than in most languages. I have some multithreaded Python programs myself, ones that are accessed through a web server and themselves access other web sites. They run unattended 24/7 with very little attention. You have to do error handling properly, but once you get it right, it just works. (See "sitetruth.com" if you're interested.) For this 'bot problem, I'd use one thread per process and use a local MySQL database for the work queue, interprocess coordination, and logging. --John Nagle (talk) 04:46, 17 March 2008 (UTC)
Since we now seem to agree on what the problem is I'd like to invite Betacommand to put his code into SVN and let others work on this together with him. This would greatly improve the bot and it would be an excellent learning experience for Betacommand. EconomicsGuy (talk) 05:37, 17 March 2008 (UTC)
"Why isn't the bot collecting the warning messages and inserting them on the talk pages in one edit?" - don't know. I suggested that when I said (in that thread): "Can't you just make a list as the bot does the tagging over 10 hours, and then run a program to consolidate the listings, and then do a separate run to notify each user once?" - I see now that Betacommand never answered that question. But let's wait and see what Betacommand says. I do hope he will talk to you two, as you seem to have some good insights here. Carcharoth (talk) 06:17, 17 March 2008 (UTC)
Since we now seem to agree on what the problem is. To be honest, several people who have never seen the code have speculated on a likely cause of the problem. We still do not know what the problem actually is. Keep in mind, all this speculation is because one image was retagged, it was speculated this might have to do with data lag, the reason for the data lag is most likely the multithreading, and if that's the case then there is probably an intelligent way to make this to work correctly. I notice Carcharoth has asked Betacommand on his talk page to shed some light on this. I suggest we not put the cart in front of the horse in the meantime (although to be clear, I don't oppose your request to check the code into SVN, I'm just saying that I'm not seeing this thread as any more significant evidence that this should be done than many other threads).
I would like to understand why Cobi's third suggestion would not be workable (log to a database instead of post to talk pages, then post them all at the end). But like so many threads on Betacommand, I fear that we lump so much into one thread that many things get lost and never answered. I'm of the mind that it might be most effective to generate a list of questions (no commentary, just all the tech questions we all might have) and ask Beta to respond one by one. Threaded conversation is good for many things, but one of those does not seem to be getting every question answered (in all seriousness, it's like a second job keeping up with all the Betacommand threads, so it's not suprising things get lost and missed). - AWeenieMan (talk) 12:18, 17 March 2008 (UTC)
I also don't see why logging to a databse wouldn't work. I know there are other issues and these things tend to get lumped together in one thread but the threading issue is serious and the cause is likely to be a common error people make when trying to use threads. The threads shouldn't be crashing like that nor should he be getting "random" server errors. These are general programming issues and we need to start somewhere. Let's see what Betacommand has to say. EconomicsGuy (talk) 14:04, 17 March 2008 (UTC)
its nothing as major as processing lag, the proccessing lag has two areas, (changing the license template, which can take a few hours to process due to the sheer number of images that need to be gathered.) image processing (at most a few minutes and normally under a minute). The first step gets all transclusions of {{non-free media}} sorts them alphabeticaly and saves that list to a file. (takes about 20-30 minutes if the servers are playing nice and give me all of the images). that step produces ~59 files that each contain 5,000 images. once I have the master list of all non-free media, the next part starts. I load 10 files into memory and then create a processig threads that each check 250 images. it grabs the page text, list of pages using that image, then a set of queries that get redirects to those pages. it compiles all of that into a working regex, and tests it on the page text. (takes maybe a minute). if the image fails the regex it tags the image, loads the uploaders, and artilce talkpages and notifies them. and then moves on to the next image.
in this case it was a minor error in the regex generation, that did not take into account for the mixed use of _ in this case the title was page (disambig_part), this is the first time I have seen this and will fix the issue. βcommand 2 14:43, 17 March 2008 (UTC)
Thanks for that Betacommand. Have you tried to put the talk page notices in a queue as suggested above? That would reduce the number of edits you need to do and the risk of the bot getting in an edit conflict. I know there's still the remote chance of an image being deleted and so on while the bot is working but at least it would reduce the number of edits you need to make and thus the need to sacrifice error checking etc. for speed to get the job done. EconomicsGuy (talk) 20:00, 19 March 2008 (UTC)

Betacommand and SVGs

Betacommand has been mass-tagging raster graphics with {{Vector version available}} for speedy deletion. As the file formats are different this is not covered by CSD I1. It should be noted that at present Commons hardly ever deletes these images (relevant discussion there). Of course what Commons does is not really relevant to here and with the majority of these images there is no real reason to keep the files. However, it makes me wonder if the current CSD I1 is really an appropriate way to delete these files.

There is one critical case where the original image should be kept even with a perfect SVG replacement: That is where the SVG is a derivative of the raster graphic and the raster is under a license other than PD. In these cases, the original graphic should be kept for licensing considerations. I did a bit of digging and found two sets (PNG/SVG and PNG/SVG) of images with this problem and there are probably more. In fact as it currently stands the first SVG I've mentioned is actually a copyright violation (as the disclaimers have been removed).

The quantity of images tagged (and deleted, mostly by East718 apparently) means tracing files in need of restoration is tricky.--Nilfanion (talk) 00:01, 2 April 2008 (UTC)

I'm a bit disappointed that I wasn't even contacted before this, but what's done is done. I just happened to be working CAT:SD at the time these images showed up, and plenty of other admins have probably done deletions of this nature too - I know Wizardman (talk · contribs) did a couple hundred of them today too. That said, I'm willing to mass restore images if you can put together a list. east.718 at 01:06, April 2, 2008
Couple hundred's pushing it, I'd say. 'twas closer to 50. If consensus is to restore them then I'll restore them, though. Wizardman 01:19, 2 April 2008 (UTC)
when images are re-uploaded to a new title, all information should be contained there. per the GDFL it should contain all needed parts. if an image requires outside sources to maintain GDFL its in violation of GDFL itself. βcommand 03:21, 2 April 2008 (UTC)
What bearing does this have on the fact that you've been tagging images that aren't covered under any speedy deletion criterion? —David Levy 03:31, 2 April 2008 (UTC)
Beta, getting defensive and using other people's errors to excuse careless botwork isn't particularly helpful.
That said, if none of the images that were tagged for deletion were in use, I would consider that a likely sign that the editors had decided the SVG was better, so there probably wasn't any real harm to content done here. We probably still need to double-check the licenses though. --erachima formerly tjstrf 04:27, 2 April 2008 (UTC)

I fail to see what the issue here is. Why do we want to keep duplicate images? We don't need two versions of every image, so whats the problem with basic performing housekeeping tasks and deleting one of them? - Rjd0060 (talk) 03:58, 2 April 2008 (UTC)

The problem is that the community hasn't been given an opportunity to review the images and determine that the vector version is comparable or superior to the raster version. —David Levy 04:17, 2 April 2008 (UTC)
Wouldn't that be happening at each article where a Vector version replaced a raster, and in those cases where the vector was found superior, it remained, allowing the raster to appear to NOT be in use, and thus easier to delete? That is, although wiki-wide consensus for a policy level decision was not determined nor sought ,the relevant articles, on a case-by-case basis did create consensus for those images relevant to their articles? ThuranX (talk) 04:32, 2 April 2008 (UTC)
Unless an actual discussion has occurred, it isn't safe to assume that anyone other than the user responsible for the replacement has compared the two images. In fact, it isn't even safe to assume that the user responsible for the replacement has compared the two images. Some people believe that vector images are automatically and unconditionally superior to raster images, so they indiscriminately perform such replacements en masse. Sometimes (especially when it comes to articles with relatively little traffic), these edits remain unchallenged for months before someone notices that the vector version is an inferior substitute. That's bad enough, and deleting the raster versions without review makes matters worse. —David Levy 05:39, 2 April 2008 (UTC)
Please also note that SVG vector images can still be problematic because different rendering engines display them differently. The Mediawiki SVG renderer messes some SVG images up pretty badly. Whenever I upload SVG graphics of my own making, I usually upload a PNG duplicate for safety. Fut.Perf. 06:07, 2 April 2008 (UTC)
Deleting PD media that is no longer in use needs to be justified, as it makes viewing old versions of articles difficult, and prevents people from checking the SVG image, from seeing what the SVG is a derivative of, and verifying that the licensing is all in order. Deleting them breaks the process of continual review. IMO, they were badly tagged; was this an approved task?? John Vandenberg (talk) 06:27, 2 April 2008 (UTC)
As far as I can tell, this was Betacommand himself, probably running a script over a list, not the bot account. Whether this sort of thing needs approval is debatable, but what is clear is that, like any semi-automated process, once issues arise, tagging should stop and those who did the tagging and deletions should participate in the discussion and help clear things up. Simply participating briefly and then forgetting about it, or hoping others will clear up the mess, is not an option. Carcharoth (talk) 10:02, 2 April 2008 (UTC)
You're right; from Special:DeletedContributions/Betacommand, I count 550 that have been deleted. John Vandenberg (talk) 10:21, 2 April 2008 (UTC)
Image:Diamond road sign junction crossroads.svg is a derivative of the (deleted) Image:Diamond road sign junction crossroads.png. The SVG links back to the en page, but GFDL requires the author to be identified. If any of the SVG are derivatives of a copyleft work, but are not copyleft themselves that is copyright violation, but are there any? These things were not taken into consideration before tagging, and need fixing. Likewise is the SVG actually better than the deleted file? Definitely not always: Image:AOCWorldMap.png was tagged two days in succession and was declined the first time for that reason. Discussion of each of these images is needed, and wasn't carried out. I think the best course of action would be to restore them and possibly send to IFD en masse.--Nilfanion (talk) 11:51, 2 April 2008 (UTC)
I agree with restoring them, but I dont agree that an IFD for them all is desired. I dont want any deleted for the reasons I gave above, and afaik, there is no benefit in deleting them - they take up just as much diskspace when deleted as they do when visible to non-admins. John Vandenberg (talk) 13:07, 2 April 2008 (UTC)
I've never quite understood this idea of deleting non-attack/spam, free images. Their staying on the servers forever regardless of if their deleted or not. But as mentioned, it does make it harder when your viewing history versions or if you need a certain format for a certain use (not everything can handle svgs). Orphaned free images aren't bad, its only attack or spam images, regardless of use that are inherently bad. And of course there is the argument that even a duplicate free image could be useful in different contexts (as in a svg for a thumbnail and a png download for an MS Publisher document). MBisanz talk 17:08, 2 April 2008 (UTC)
I'd just like to say that I'm against the deletions of these sorts of images in general as well. I can restore the files, or post a list somewhere if others wish to do so.--Nilfanion (talk) 20:59, 3 April 2008 (UTC)
I, too, oppose the deletions and think the images need to be restored. The deletions were completely unnecessary with no benefit to the project, and we already have a process for leaving pointers to improved versions of an image. Are there people who just get a kick out of clicking the delete button? rspeer / ɹəədsɹ 04:44, 4 April 2008 (UTC)

I briefly mentioned this thread at the arbitration case, and one of the arbitrators has requested a layperson's summary. See here. Can anyone oblige? I'm afraid raster and vector image stuff goes over my head a bit too, though I remember it being not too difficult to understand one you stip away the jargon. Carcharoth (talk) 01:25, 4 April 2008 (UTC)

OK, I've created a list of the files that were tagged for deletion with this rationale - the list is here. In total there were 711 deletions (not ~550) stemming from these events. The blue links on the list are from Commons images showing through, some of which are the same as the WP file and some are not. Probably easiest just to restore everything and for those files with Commons duplicates check CSD I8 is met before redeleting.--Nilfanion (talk) 10:43, 4 April 2008 (UTC)

East718 can undelete those in a second with some tool he has. MBisanz talk 14:40, 4 April 2008 (UTC)
But nothing has been done yet. Did anyone ask him? Also, could someone tweak the list to show which ones have Commons images? Otherwise the link being blue is misleading in those cases. Carcharoth (talk) 22:11, 7 April 2008 (UTC)
Is User:Nilfanion/SVGlist comprehensive? If so I'll ping east, but someone will still need to remove all the db tags. MBisanz talk 22:21, 7 April 2008 (UTC)
Betacommand could remove the db tags, surely? Carcharoth (talk) 22:24, 7 April 2008 (UTC)
Well you probably should ask him at his talk page, this page has died down over the last week or so. And yea, East should time his undelete with Beta's availability so that admins do go trigger happy. MBisanz talk 23:58, 7 April 2008 (UTC)
I will go and ask him, though he may be involved with something else at the moment (involving talk page redirects). Carcharoth (talk) 13:02, 13 April 2008 (UTC)

Purpose of this page

I've raised my concerns at Random832's talk page about this already, but I think some wider input would be nice. Currently, pretty much every thread about Betacommand is moved to this subpage. Is that what we want? Initially, this page was created because issues surrounding Betacommand took up half of WP:AN/I at one point, after all. I don't think this was intended by anyone to be a permanent subpage of the noticeboard, but that's what this'll turn into if the threads continue to be moved here. There's no real need for that, IMHO, as WP:AN/I can handle the recent threads about Betacommad just fine. So, should we keep this page active? --Conti| 17:18, 2 April 2008 (UTC)

A reason I can think of is the proposed remedy in this Wikipedia:Requests_for_arbitration/Betacommand_2/Proposed_decision#Review_and_future_remedies. If the Arbcom is stating that if future disputes occur, it will look at future patterns of behavior, having all the "evidence" in one place would make it easier to document.MBisanz talk 17:21, 2 April 2008 (UTC)
Hmm, maybe we could do it the other way around, then, and link from this page to the corresponding WP:AN/I threads. It shouldn't be too hard to collect/find evidence either way. --Conti| 17:25, 2 April 2008 (UTC)
I'll note that I'm probably too involved to make a decision in this case and would defer to more uninvolved opinion. MBisanz talk 17:34, 2 April 2008 (UTC)
I'd say just keep discussion on AN/I. If people are concerned about evidence collection for ArbCom this page could link to the appropriate threads on AN/I and when the discussion is archived there as normal, either link to the AN/I archive or mirror the content over to this page. Mind you recording everything even tangentially related to Betacommand could give the appearance of a witch-hunt, in expectation of a future arbitration - which is probably not a good thing to be doing.--Nilfanion (talk) 21:06, 3 April 2008 (UTC)

I know I didn't intend for this page to be a permanent location for all BetaCommand related issues forever. It might be useful to give it another 60 days, so that all the edits are in a history that is easier to review than AN/I. On the other hand, WP:AE serves roughly the same purpose once the current arbitration case is closed. When the case is closed, I think this page can be archived (but not deleted of course). Avruch T 21:16, 3 April 2008 (UTC)

I am interested to find out just now there was such a page as AE, and I wonder who knows it is there, as considering there was a betacommand1 case relatively recently, I never saw a single ANI thread moved or transd to AE in the last few months. It might have prevented case 2. MickMacNee (talk) 22:45, 3 April 2008 (UTC)
There was no required enforcement for the case Betacommand (unlike, say, Highways here), so there was never any real need to move threads related to Betacommand there, unless he violated another Arbitration case. x42bn6 Talk Mess 22:49, 3 April 2008 (UTC)
All the admin noticeboards are linked to from the top of the WP:AN page (The template). Avruch T 22:52, 3 April 2008 (UTC)
This one {{Editabuselinks}} MBisanz talk 22:55, 3 April 2008 (UTC)
(ec)Correct, the matters of the last several months, have nothing to do with the BC1 arbcom, so AN/I was the right place. And a witch-hunt is a concern, but I suspect that 60 days would be a reasonable time to keep this page open and then archive it/courtesy blank it. MBisanz talk 22:54, 3 April 2008 (UTC)
Realy? Wikipedia:Requests for arbitration/Betacommand. Mistakes, incivility, poor judgement, poor communication... You could even look at Unsatisfactory communication regarding image deletions and compare with the SVG discussion above. MickMacNee (talk) 23:09, 3 April 2008 (UTC)
IIRC, BC1 dealt with his de-sysopping for those issues. Admins are held to a higher standard of conduct IMHO, so what might be poor judgement and poor communication for an admin, might not be the same for a non-admin. MBisanz talk 23:26, 3 April 2008 (UTC)
The the indefinite loss of gregs the baker for snapping at the mackem sock, and my ban for 6 days for challenging DCGeist with consensus, without any reply from the blocking admin, and now the above comments about bc1, I pretty much have no clue as to what any of the blocking standards or norms are. MickMacNee (talk) 23:41, 3 April 2008 (UTC)
Gregs has sent me extensive and difficult to understand evidence, as well as invoking his RTV. I'm presently trying to make sense of it all, but if he does not, I may just forward it on to arbcom. And, well, yea, things happen the way they happen, if everyone was going to AE for BC, then we'd have an AE subpage, but people went to AN/ANI, so we have this subpage. I sincerely doubt the current situation would have been different based on which page it was sub'd to. MBisanz talk 23:49, 3 April 2008 (UTC)
WP:AE is only for the enforcement of Arbitration cases, i.e. the Enforcement section. I don't think it's meant to act on violation of Principles or Findings of Fact. Actually, I would be quite miffed if we started sanctioning mistakes - we are humans, after all, aren't we? x42bn6 Talk Mess 12:27, 8 April 2008 (UTC)

Betacommandbot 9

For all interested parties who haven't noticed, this to note that betacommand has applied for approval for a new function for betacommandbot [4]. Speak now or for ever hold your peace. AKAF (talk) 06:48, 17 April 2008 (UTC)

Betacommand incivility post arbcom 2

For the archive Wikipedia:Administrators' noticeboard#Immediate_incivility_from_Betacommand_following_arbcom_case_2 MickMacNee (talk) 12:45, 18 April 2008 (UTC)

Re-visiting an indefinite block - Betacommand

Resolved
 – Boldly closing this discussion as no consensus to unblock. It seems that it is too soon for the community to revisit this matter. LessHeard vanU (talk) 13:11, 10 January 2009 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There is a thread here regarding setting a specified duration for Beta's currently indefinite block. Because Beta cannot edit elsewhere and in the interest of keeping discussion centralized, please comment there, not here. Cheers. --MZMcBride (talk) 05:43, 6 January 2009 (UTC)

I think that discussing the block here is a more appropriate venue, so that's what I'm going to do. Beta is (of course) free to reply on his page, and I'll read his reply.
"Madness" has been defined as "Doing the exact same thing over and over again and expecting a different result." It's unclear to me what, exactly, has changed since the other 40 (or however many) times Beta has been blocked. Certainly, I've seen no indications from him personally that he's had a change or heart, or that he recognizes the seriousness of his misbehavior. Until such time as we see that from him, rather than from his advocates, I strongly oppose any sort of unblock. Nandesuka (talk) 14:00, 6 January 2009 (UTC)
The thing is, MZMcBride is suggesting that BC is unblocked, with the same old restrictions as before and that we all go on our merry way. The thing is, that will not work, as in the previous discussion he did not even acknowledge the restrictions placed against him (he was well aware of them, he just chose to give two fingers up to them instead). Besides, a month for a block is far, far too short, particularly when you consider that some people have been indefinitely blocked for much less than this. He will only merely "ride it out" as usual, as he himself says, rather than learn anything from it. Time and time again there's big debate about it here at AN, and it's nothing but a drain on Wikipedia's resources and waste of time for everyone involved. He "apologises", then he snaps at someone or whatever, and then he's blocked again. No other editor on Wikipedia has had as many chances as him. Betacommand is a problem. And rather than dealing with the problem, it is simply being left to spiral out of control, as we have seen already. This method of dealing with it simply does not work. It's time to put the foot on the floor and lay down the law. He may one day wish to return as a civil, collaborative, editor, but this will never happen unless he is made to realise that what he has been doing is simply unacceptable both now and in the future. Giving him the easy route out, yet again, is not the way to do it. He needs time, at the very least. --.:Alex:. 16:50, 6 January 2009 (UTC)

Can we just move the whole discussion here? It would be best to have it in one place and AN is a better forum for this discussion than Betacommand's talk page. He's got enough people watching his talk page that if he wants to comment, somebody can copy it over. -Chunky Rice (talk) 17:53, 6 January 2009 (UTC)

There's something surreal about someone making edits that nobody seems to question, and getting indef blocked for it. The block isn't for the edits, it's for who made them and how. Even if that merits a block, "indef" doesn't fit the normal escalating block pattern. Some definite time frame should have been set. Personally, I have a difficult time justifying any block longer than double the previous longest. Gimmetrow 18:28, 6 January 2009 (UTC)

This is sort of a surreal argument. By my count, Betacommand has been blocked 26 times (not counting blocks of his various Bot and known public sock accounts). If we imagine that the first block was a 1 hour block, and that we doubled the duration for each violation, the present block should last for 33,554,432 hours, or 3,830 years.
When someone keeps digging a hole this deep, at some point adults are required to step in and take the shovel away. Nandesuka (talk) 20:35, 6 January 2009 (UTC)
It's also a surreal argument because it ignores the fact that these were not "edits that nobody seems to question". See among many others [5][6][7]. The fundamental misunderstanding here is that BC supporters look at the edits themselves and see no problem. For the admins constantly dealing with the shitstorm that comes when people question the edits and BC inevitably tells them to fuck off, the problem is not the edits: it's their timing, their labelling as vandalism reverts, the ensuing unresponsiveness and aggressiveness on the part of BC. There's something surreal about an editor that needs to be indef blocked before he acknowledges any kind of responsibility for his actions. BC did do a lot of good on the project but over the last months, his unwillingness to change how he does business has made him a liability. Pascal.Tesson (talk) 03:35, 7 January 2009 (UTC)
The shitstorms are at least partly, if not largely, due to quite a few editors' failure to deal with these cases in a mature, adult manner. Nothing seems to have changed. Gimmetrow 04:56, 8 January 2009 (UTC)
Whereas Betacommand has handled this with calm and dignity? I'd love to hear some names from you. Ryan Postlethwaite, Jennavicia, CBM, LessHeard vanU, myself are the admins who were most involved in the last three months and I'm interested: who among these showed an inability to deal with the case in an adult manner? Or was that perhaps Sam Korn? Or maybe the ArbCom back in April? It's time for you to acknowledge that a lot of very reasonable people have worked hard to provide Betacommand with a way out of this mess and that your vague "quite a few editors" refers to editors whose calls for BC's head have had only slim impact. Pascal.Tesson (talk) 20:45, 8 January 2009 (UTC)
Actually, the worm has turned. Betacommand supporters, the few that are left, have either forgotten or didn't know that it used to be the other way - that he had many supporters, and any attempt at blocking him was usually snuffed out, shortened, or whatever; but as each incident occurred, and his attitude asserted itself again and again, his many supporters gradually peeled off, and left the current situation. Baseball Bugs What's up, Doc? 23:05, 8 January 2009 (UTC)
Actually, the "Sam Korn solution" is a good example of the inability of "The Community" to deal with this properly. The "Sam Korn solution" had obvious problems which were pointed out at the time. "The Community" didn't acknowledge these problems. They accepted the "Sam Korn solution", which nevertheless failed exactly as had been predicted. Exactly. Gimmetrow 00:56, 10 January 2009 (UTC)

Re-visiting your most recent block

Moved from User talk:Betacommand

An indefinite block here seems inappropriate. Generally speaking, a user is indefinitely blocked when no admin is willing to overturn the block, however, in this case, that is not the case. I propose setting the block to a specified duration on the condition that Beta not make any further automated actions (or bot-like actions) from the account (things like using Twinkle for CSD / AfD tagging excluded). If Beta resumes bot-like editing, the block can be re-set with an increased duration. However, I hope (and believe) that will not be an issue in the future. I propose a specified duration of one month. --MZMcBride (talk) 05:42, 6 January 2009 (UTC)

Seems reasonable to me - the user is clearly a good-faith user who has problems with understanding when automated editing is problematic. I think, though, that we should be more specific with what's meant by "things like using Twinkle for CSD / AfD tagging" - since this user has a history of not using proper judgement when deciding what's appropriate in this area, this clause is one which I believe he will apply beyond what's meant. עוד מישהו Od Mishehu 06:51, 6 January 2009 (UTC)
No a user can be indefinitely blocked by any admin. You are are referring to a de facto ban, which does not exist in this case (because some admins like yourself have expressed their willingness to unblock). Beta remains indefinitely blocked because there is consensus for that to happen - should consensus change he will be unblocked or a duration will be set. Remember that indefinite does not mean infinite. ViridaeTalk 08:02, 6 January 2009 (UTC)
Eh? That's a bit too much parsing of block versus ban for my tastes. :-) Regardless, I want to specify a duration for the block as I feel the current duration isn't appropriate. Whichever steps head in that direction I'm in favor of. Cheers. --MZMcBride (talk) 08:23, 6 January 2009 (UTC)
(ec)Agreed. If MZMcBride would like to revisit this he should start a new discussion at WP:AN (but I'd wait; the other discussion from WP:AN/I is only a few days old and no consensus was reached). —Locke Coletc 08:25, 6 January 2009 (UTC)
I put a note at WP:AN pointing here and explaining my choice of venue. :-) --MZMcBride (talk) 08:42, 6 January 2009 (UTC)
I would have appreciated a note on my talkpage, especially as you feel my indef block was inappropriate, as I would argue that the case is for Betacommand to provide a basis for unblock rather than find fault with the block - which had consensus at the time. I see no proof yet that consensus, rather than the views of some, has changed. LessHeard vanU (talk) 13:43, 6 January 2009 (UTC)
Support unblock: I strongly support the review of the indefinite block of BC. The block may be only for a specified duration and BC should be able to continue to contribute to the project ( and may be without the bot like edits). -- Tinu Cherian - 08:38, 6 January 2009 (UTC)
Oppose unblock, nothing seems to have changed since the last time we seemed to get consensus for the indef block, thus I don't see why we need to be revisiting this at this stage. Additionally, I object to the choice of venue for this, a place like WP:AN would get more views and a greater diversity of input, and any conclusion arrived to there would be seen to have greater legitimacy. Lankiveil (speak to me) 09:08, 6 January 2009 (UTC)
I oppose an unblock until we have a clear indication from beta that he knows why this situation continues to occur and that he understands the community is losing (has lost?) patience. I also disagree with the venue. ViridaeTalk 09:32, 6 January 2009 (UTC)
Support immediate Unblock just as soon as Betacommand accepts that what he did was outside of the terms of his restrictions, that the restrictions still apply, and he will be indefinitely blocked again should he violate them again. I would comment that should he be unblocked and later blocked again for the same or similar violation of the restrictions - which does include a civility parole - that the demand for a ban might be so considerable that it would be unlikely there will be a sysop willing to unblock. Providing the Betacommand understands that, then there is no need to serve any further definite period of sanction. LessHeard vanU (talk) 13:35, 6 January 2009 (UTC)
LessHeard vanU, I made that statement already. [8] βcommand 15:02, 6 January 2009 (UTC)
Thank you for reminding me; I trust you also understand it also, but per AGF I am therefore inclined to support unblock per your post as linked. However, it still requires consensus from the entire community for it to happen. LessHeard vanU (talk) 22:11, 6 January 2009 (UTC)


Support immediate unblock - per LHVU. I would further suggest that for the time being, Betacommand has his process generate lists of the content he would like to remove, for review at VP or a subpage in his userspace, per Newyorkbrad's suggestion above. //roux   13:55, 6 January 2009 (UTC)
"Madness" has been defined as "Doing the exact same thing over and over again and expecting a different result." It's unclear to me what, exactly, has changed since the other 40 (or however many) times Beta has been blocked. Certainly, I've seen no indications from him personally that he's had a change or heart, or that he recognizes the seriousness of his misbehavior. Until such time as we see that from him, rather than from his advocates, I oppose any sort of unblock. I also concur with Viridae that this discussion should be taking place on WP:AN, and I will encourage people to talk there. Beta is free to read that page and respond here if he likes. Nandesuka (talk) 13:58, 6 January 2009 (UTC)
Oppose unblock - it's far, far too soon since we last failed to gain consensus. What exactly will have changed in this short time? Also, I too dispute the choice to hold this discussion here - a central location such as AN will attract more (much needed) attention. TalkIslander 14:02, 6 January 2009 (UTC)
Oppose unblock per Islander.--Berig (talk) 14:05, 6 January 2009 (UTC)
Oppose unblock per Nandesuka. I'm not convinced that Betacommand will be able to edit in anything resembling a collaborative manner. I'm concerned that we will be going through the whole circus again in a week if he's let back in. *** Crotalus *** 14:49, 6 January 2009 (UTC)
Support unblock with the clear understanding that this is Beta's last chance. I disagree with the latest block in the sense that the task was not at all controversial (removing images w/o valid rationales from pages) but only merited the block on Beta due to the community restrictions. Beta needs to be absolutely clear if he decides to take a task that may appear automated, per the community restrictions, but also make sure to get any clarifications he needs to make sure he doesn't violate them even if he gets the necessary consensus to proceed. If unblocked, admins need to be aware that there are people that will likely want to goad Beta into some type of violation, so if another (and effectively final) block is called for, there needs to be a thorough review of the evidence to make sure it was truly in Beta's means to avoid. --MASEM 15:01, 6 January 2009 (UTC)
Support unblock, FWIW. The choice to have the discussion here instead of at AN is perfectly acceptable; as MZMcBride pointed out, Beta is unable to contribute anywhere but here. The statement that he linked to for LessHeard vanU is sufficient for me. GlassCobra 15:44, 6 January 2009 (UTC)
I oppose this choice of venue, the timing of this request for reconsideration, and I strongly oppose the unblock at this time. We've really only just concluded the previous community discussion affirming the indef block and it seems bizarre to try to resample the community in this way after such a short duration. The feeling there, which I share, is that we seem to have offered Beta many, many so-called "last chances" to collaborate effectively, but at present seems unable to do so. Fritzpoll (talk) 15:57, 6 January 2009 (UTC)

Betacommand - Arbitrary break one

I don't oppose a limited duration block, but this is not the venue this should be discussed at and any unblock not decided in a forum with lots of eyes is going to cause more problems and be quickly overturned and invalidated. AN it... rootology (C)(T) 14:54, 6 January 2009 (UTC)

  • This situation is ridiculous. A handful of users have been hounding Betacommand to death. There's no way they could be happier than the day when Betacommand is banned from the site for life. It doesn't matter if it makes sense to block him or not. I look at his last 100 article contributions, and what he was doing was perfectly within policy. He gets blocked. In fact, he gets blocked indefinitely. I conducted a similar set of edits, and nobody blocks me.
  • Now we're in a situation where we have to have consensus to unblock him???????? That'll never happen. The people that want Betacommand gone from the site permanently have won. The ban is permanent now because there will never be consensus to unblock him. What a bunch of hoo haa.
  • Some administrator needs to have the guts to unblock him and take this matter to ArbCom for review, rather than let the lynch mobs run Betacommand off the project. --Hammersoft (talk) 16:27, 6 January 2009 (UTC)
  • My point was just that if anyone unblocks Beta based on a consensus formed on this page, or anywhere but AN or ANI, it will start a fire that will end at WP:RFAR and probably leave Beta reblocked in the meantime. Unless if the goal is to rocket launch it to RFAR, then go ahead... it sucks, but I can't imagine it going any other way. rootology (C)(T) 16:42, 6 January 2009 (UTC)
The situtation is hardly ridiculous - it is unnecessary distracting large scale drama. BC earned his block through repeated incivility and by ignoring the terms of his continued participation here. Trying to perform some sort of end run through a meaningless vote on a talk page is far more ridiculous. I for one am content to see him cool his heels on the sidelines for an extended period so that there is some measure of peace, and when and if he does return he needs to clearly demonstrate through his actions and demeanor that he gets it. It might start with some selflessness and acceptance of the current circumstances and what drove it to this. Wiggy! (talk) 16:42, 6 January 2009 (UTC)

I strongly oppose unblocking BC. We have already given BC way too much credit. Any other user would have been indefblocked a lot earlier. Everything we have done to try and make him change his ways (desysopping, ArbCom, restrictions, you name it) has failed. Why allow him to return under restrictions when he has already blatantly violated those restrictions? How many last chances can you give to someone? Aecis·(away) talk 17:15, 6 January 2009 (UTC)

  • Oppose unblock for the time being. While this may be considered an apology and/or admission of wrongdoing, I am not comfortable with an immediate unblock, given the comments raised in the past. seicer | talk | contribs 18:50, 6 January 2009 (UTC)
  • I've hesitated to get involved in this, and this will be my only post here, but after reading Hammersoft's accusatory post, I must respond. As a user who has (under a previous account) tangled with BC, and received the blunt end of his personal attacks, I feel that unblocking now would be a major mistake. Are there some users who annoy BC? Sure. Does that justify the way he treats almost anyone who dares disagree with his interpretations of policy? Not in the least. I strongly support a long block, until BC fully grasps that his interpretations of policy aren't the only interpretations of policy, and that the personal attacks he traffics in are completely unacceptable, and pledges to never engage in such behavior again. SDJ 19:47, 6 January 2009 (UTC)
  • Support Immediate Unblock - Unblock and next infraction keep lengthening blocks. Chrislk02 Chris Kreider 20:09, 6 January 2009 (UTC)
  • Comment Beta has shown contrition and indicated a (partial) plan to edit in a more acceptable manner, which is good. However, much of the problem arises because of Beta's focus on NFC issues and his apparent belief that his interpretation of NFC policy is the policy. If Beta would agree to confine his NFC activities to talk spaces (let's say for 3 months), that would give him a chance to show improved civility and communication skills. Having an interlocutor and overseer (not necessarily Roux though) would also be good. If Beta would also adopt NewYorkBrad's suggestion for putting proposed edits on sub-pages of his talk, then I'd support an immediate unblock. Existing restrictions would of course continue to apply. Franamax (talk) 20:43, 6 January 2009 (UTC)
    • Fran, I certainly wouldn't want to be said interlocutor. Apart from whatever other issues people will happily invent to say why I shouldn't be, I simply don't know enough about the NFC rules to be able to comment on them with any degree of insight. //roux   20:57, 6 January 2009 (UTC)
      • I think a much safer option (along this line of thinking) would be to just give Beta an outright topic-ban on NFC. That's where he's caused most problems, so take that out of the equation and perhaps it might help. Having said that, I oppose an unblock at this time, as I've stated above. TalkIslander 22:11, 6 January 2009 (UTC)
        • Yes, a topic-ban might be "safer" but I'm not sure it would be a net benefit. Beta does have extensive knowledge and perspective on NFC issues and an ability to make large-scale tools to gather and analyze information. That's not the problem - the problem is Beta's method of executing on these abilities, which consistently gets him into trouble. He makes direct actions in live spaces and when questioned adopts a (shall we say an, ummm, somewhat) defiant approach. Take away the temptation to "edit-first, defy-later" aspect and Beta can have a chance to demonstrate an expanding diplomacy skill-set - or not, as the case may be. He does have valuable skills, it's his implementations which are problematic. Given Beta's own input so far, I'd agree not to unblock. If he can agree a way out though, I'd say sure, one more try. One more. Franamax (talk) 23:11, 6 January 2009 (UTC)
  • Oppose unblock We just had this whole discussion less than a week ago with a strong consensus for the block to stick. We can revisit this in a month but now is not the time. The same old arguments are being made by those supporting yet another last chance for BC and none of them are reality-based:
  1. Betacommand has shown contrition. Yes, he did so after being blocked indefinitely. May I remind people that his initial reaction doesn't show much contrition. In response to an earlier request to stop automated runs of edits he responded with this. When I blocked him a few days prior to the last incident, contrition was not exactly evident either [9]. So AGF and all, it's kind of hard to take the apology seriously.
  2. If these edits had been made by someone other than Betacommand, nobody would care. That's true of any editor who isn't under editing restrictions. Betacommand was under clear, unambiguous restrictions. And as I said in the debate a week ago, the mass edits were made in the middle of a contentious RfC and though they were indeed in line with policy, the timing was certain to generate useless drama. This is precisely the kind of shoot first ask questions later attitude that led to the editing restrictions.
  3. Betacommand is being stalked by a lynch mob. I, for one, have never seen myself as a rabid extremist and generally support tight restrictions on free images. Ryan Postlethwaite is not a maniac just waiting for BC to slip up. Jennavecia and CBM who were involved in formulating the last restrictions are not out to get him. While there are indeed people who wish to see BC banned for eternity, the fact is that many people have tried to find reasonable ways to resolve the problems posed by BC. We've tried to engage him, tried to explain as clearly as possible the blocks we put in place, tried to warn him when he was stepping over the line. And we failed.
  4. Betacommand is just enforcing NFCC. Yes he is. But you can enforce NFCC without resorting to hostility and bullying. And because NFCC is the source of so much bickering, enforcing it requires tact and patience. It also requires conflict resolution abilities which BC seems to lack. As such, his involvement in enforcing NFCC is a net negative for the project.
  5. Betacommand is well intentioned. Yes he is. This is unfortunately irrelevant. You can be well intentioned and still hurt the project. When you're unable to tolerate dissent and criticism, your well-meaning edits will inevitably be dwarfed by the ensuing drama.

There is quite simply no basis for an unblock this early. Pascal.Tesson (talk) 22:35, 6 January 2009 (UTC)

  • Comment -when Beta's block eventually ends up getting shortened down, please spare the stomachs of those who have been actually paying attention by not bothering to say "Awright, but this is REEEEEALY your last chance this time!". Saying so only proves that you didn't bother to read the last three (yes, three) "Last Chance" unblock agreements Beta agreed to. We have now entered the Groundhog Day zone. Bill Murray will be along at 00:01 to create an identical clone of the last Beta AN thread so we can pack this one into the attic with the others. Bullzeye (Ring for Service) 23:39, 6 January 2009 (UTC)
  • Oppose unblocking to prevent Betacommand from engaging in further extensive bot-assisted disruption and severe incivility. John254 23:51, 6 January 2009 (UTC)
  • Support unblock with complete tool strippage, unless the tools do not involve contact with other users. NuclearWarfare (Talk) 02:20, 7 January 2009 (UTC)
Beta was not a fan of this option last time it was suggested. [10] Pascal.Tesson (talk) 03:39, 7 January 2009 (UTC)
  • Oppose unblocking per reasons stated by Pascal.Tesson. Beta's post-block contrition rings hollow, especially when it comes after his usual threats against the blocking admin failed. Enough's enough, and I don't see any proof that BC's behavior will ever change. BrownHornet21 (talk) 06:19, 7 January 2009 (UTC)
  • Support unblocking with conditions. I made the original report and I was frankly astounded by the magnitude of the response. I know everyone is fed up with Betacommand -- and I am too -- but I don't think this is the event that should get him banned. He needed to be blocked for breaking his agreement and basically giving his agreement the finger, but (as it was quite a minor violation) it's not the kind of thing we should be banning for, and this block is a ban if we never lift it. I'm not gullible enough to suggest that we should put things back the way they were and say "last chance", though. I think that at a minimum, we need to:
    • Include Betacommand's editing restrictions and civility probation in his Arbitration decision.
    • Establish that "escalating block" means something. Blocking Betacommand for 24 hours is like giving someone a tip of five cents. It's worse than not doing it at all.
    • Recommend that Betacommand removes most of the tools that he is running on his account, whether they are implemented in JavaScript or any other language, and particularly require that he removes the fake rollback that he has overused in enforcing his favorite policy, as well as any tool that speeds up the removal of images. It may be true that Betacommand's account is so thoroughly cyborgified that his normal editing looks like an automated tool or a bot -- but this is his problem and not ours. Making bot-like edits comes with a subtext of "don't mess with me, I can't be stopped", and this is exactly why his editing restrictions ban him from making long patterns of edits no matter how they are produced.
    • Recommend that Betacommand should not be working in non-free image policy, whether it's debating what the policy should say or enforcing it. He's incapable of working with this policy without making everyone hate him. It might not be a literal ban from this area of policy -- that is, we shouldn't be watching and holding a Taboo buzzer to see if he says anything about non-free content -- but what everyone but Betacommand can see by now is that if he tries any further to accomplish what he wants to with the non-free content policy, he's going to end up banned and no one will shed a tear.
rspεεr (talk) 06:48, 7 January 2009 (UTC)
He's not paid any attention to "conditions" on previous occasions when he's been unblocked, what makes you think he'll pay attention to these ones now? Lankiveil (speak to me) 10:04, 7 January 2009 (UTC).
Well, the first two are out of his control, and the third and fourth are basically my recommendations for how he can fix things, so that he doesn't end up back here on AN a few weeks later and get banned. I'd just like to see some indication that he will change the things that have made him such a pariah. If he's actually making an effort to do so this time, great. If his response is something along the lines of "hell no policy is policy and I'm going to enforce it", well, might as well leave him blocked to save time. rspεεr (talk) 10:20, 7 January 2009 (UTC)
I'm all for second chances (in fact I actually supported BC's re-sysoping) but I don't think BC should be unblocked for now even under the conditions detailed above. It should be noted that Rspeer's condition 1 is actually already in place. This did not stop BC from collecting block after block since his return to editing in November. Condition 2 certainly makes sense which is why I can't support an early unblock: the current block should be for a longer period than any of the previous blocks and I won't support anything shorter than a month. BC is obviously not getting the message: he was blocked 14 times in 2008 (and that number would be higher if the civility restrictions had been enforced more strictly), agreed to restrictions that he then ignored, refused to recognize any of the blocks as legitimate, repeatedly ignored warnings and continued to view and portray himself as a martyr. Some of his supporters are now perpetuating this meme and scream "lynch mob" at every turn, conveniently ignoring the fact that the civility restrictions were first put in place by ArbCom and that the set of extra restrictions was put in place by a trio of cool-headed admins. There may indeed be a group of users who want BC to rot in hell but they're not the ones dictating the community's response to BC's continued failure to keep his promises. Pascal.Tesson (talk) 18:36, 7 January 2009 (UTC)
You know, you're probably right. I've also realized that unless I can make my suggestions really clear and concise, they'll just be full of loopholes and impossible to follow up on, so it basically does amount to saying "okay really last chance this time" like a gullible tool. It still makes me a bit uncomfortable that the relatively minor event I reported might have led to a ban, but I suppose the point is that he should have been banned the last time. rspεεr (talk) 09:29, 8 January 2009 (UTC)
Gullible tool? Your words, not mine. :-) Betacommand isn't banned, he's blocked until further notice and this can be revisited when the dust has settled (and this should take a while given the amount of dust). The terms of the unblock should probably be drafted carefully before the discussion on the wisdom of an unblock and BC supporters need to realize that they can't expect much support if they propose this too soon or are unwilling to impose restrictions more stringent than the previous ones. Pascal.Tesson (talk) 15:34, 8 January 2009 (UTC)
I agree with you entirely on this, Pascal. The smart thing to do would be for this block to be left alone for a month or two, long time until tempers have cooled, then raise the question. Bringing this issue up every week or two only serves to make those opposed feel as if they're (okay, we are) being bullied into acquiescence -- & we will only dig our heels in even deepr. And if BC can't find something else to do until then with his time, then he has a more serious problem than his objectionable behavior. -- llywrch (talk) 20:06, 8 January 2009 (UTC)

Betacommand - Arbitrary break two

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Comment I originally supported the indef block because Betacommand not only violated his restrictions, he was denying that he even had to follow them. Now that he has agreed to follow a very strict interpretation of the restrictions upon him, I don't really see a good reason not to go back to a schedule of escalating blocks. This current block should be in the 1-3 month range. -Chunky Rice (talk) 18:17, 7 January 2009 (UTC)
  • Question BC has been subjected to a block for barely more than a week. If this request is rejected (or fails due to lack of concensus), does that mean his apologists will return in a week to ask again? -- llywrch (talk) 00:40, 8 January 2009 (UTC)
  • Question If BC is unblocked, does that mean his attackers will return in a week to block him again? --Hammersoft (talk) 19:17, 8 January 2009 (UTC)
Answer: I doubt he'll last that long unblocked. He's in denial of his problems, & has a dedicated team of enablers. The best contribution he can make to Wikipedia under current conditions is to find something else to do with his time. -- llywrch (talk) 20:06, 8 January 2009 (UTC)
  • And a dedicated team of attackers. --Hammersoft (talk) 20:18, 8 January 2009 (UTC)
  • Hammersoft, at some point it should have struck you that you have a minority view with regards to Betacommand. Those who you consider "Betacommand's attackers" are a majority, and in fact aren't "attackers" at all, but merely disgruntled editors who are fed up with the drama and time wasting that Betacommand creates. Are you honestly saying that this whole situation has been created by just a handfull of attackers, and those who still posess rational thought have been unable to stop it? If that's your view, you may want to step back and look at the logic of it. To disagree with, nay, to strongly oppose the block is one thing. To call anyone who approves of it an attacker is, to be frank, a clear WP:NPA violation. TalkIslander 20:34, 8 January 2009 (UTC)
  • I have absolutely no interest in majorities or minorities, and I don't care if I'm the only person out here screaming in the wind. Betacommand was most recently blocked for doing something that was completely within policy. There's ZERO question of that. He was blocked, indefinitely. I conducted a similar series of edits, in an even tighter time frame, and no admin even warned me about my actions. Nothing. Not a peep. It's blatantly absurd that this discussion is even taking place. Betacommand's attackers are using an entirely within policy series of edits as a vehicle to shut him down, nothing more. Betacommand has been hounded to death over and over and over again. I'm surprised he's dealt with it with as much equanimity as he has. NOBODY should be surprised that he's become angry at times over it. Any reasonable person would. The treatment he has suffered under here is beyond the pale. Nobody deserves as much hatred as has been spewed at Betacommand, not even Willie. This was a bad block from the beginning. --Hammersoft (talk) 20:59, 8 January 2009 (UTC)
  • "I'm surprised he's dealt with it with as much equanimity as he has" - hehe, very funny. That aside, I assume you've heard of the expression "the straw that broke the camel's back"? Well, that's what this set of edits was. TalkIslander 21:26, 8 January 2009 (UTC)
  • "Betacommand was most recently blocked for doing something that was completely within policy. There's ZERO question of that..." - in fact, that depends entirely on how you look at the situation. The community (including Betacommand) reached a consensus as to what editing restrictions Betacommand would have to operate under. That's exactly how a policy is formed over time. Thus is could easily be said that breaking those editing restrictions carries the same weight as breaking a plain policy. TalkIslander 21:33, 8 January 2009 (UTC)
No offence, but what do you honestly expect Hammersoft? There's clearly going to be a major backlash when someone starts branding people as "trolls" and "assholes" for diagreeing with him (that's the difference between him and you when making those edits, by the way), and for you to respond to genuine critcism of such volotile actions as "attacks" and calling them a "lynch mob" is just assuming bad faith and is indeed an attack in itself. He has a severe attitude problem, and he needs to sort it out. This constant case of immediately unblocking him and giving him the all clear is simply sending the wrong message, hence why we now face this situation. Flaming people only makes matters a whole worse. We really just want to help him to help himself, with the end result being postive for everyone, especially himself. --.:Alex:. 21:06, 8 January 2009 (UTC)
Hammersoft claims that Betacommand was blocked for doing something that was entirely in line with policy. Does he claim that disregarding editing restrictions is entirely in line with policy?
Some editors are under a restriction, which limits what they are permitted to do. Betacommand is one such editor.Mayalld (talk) 21:12, 8 January 2009 (UTC)
  • Yawn. Somebody needs to have ArbCom revisit this. --Hammersoft (talk) 21:54, 8 January 2009 (UTC)
    • Why? The community is handling it quite successfully - even if it isn't going the way you want it to. ViridaeTalk 23:56, 8 January 2009 (UTC)
      • Blocking someone for doing something perfectly in line with policy isn't handling something successfully. --Hammersoft (talk) 00:24, 9 January 2009 (UTC)
        • He was blocked for breaking restrictions he was placed under. That does not qualify as being "perfectly in line with policy". Baseball Bugs What's up, Doc? 00:36, 9 January 2009 (UTC)
          • No, he was blocked because people jumped at an opportunity to ban him from the site when what he was doing is so routine even bots have done it. It was a convenient excuse to block him, and now effectively turning it into a ban from the site. --Hammersoft (talk) 00:48, 9 January 2009 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Return of Betacommand?