This is a page for working on arbitration decisions. The arbitrators, parties to the case, and other editors may draft proposals and post them to this page for review and comments. Proposals may include proposed general principles, findings of fact, remedies, and enforcement provisions—the same format as is used in Arbitration Committee decisions. The bottom of the page may be used for overall analysis of the /Evidence and for general discussion of the case.

Any user may edit this workshop page. Please sign all suggestions and comments. Arbitrators will place proposed items they believe should be part of the final decision on the /Proposed decision page, which only arbitrators may edit, for voting.

Motions and requests by the parties

Motion-Name change of the Case withdrawn by Parker007 per "Cases aren't limited in scope according to their names"

1) I move for a change of name for the following arbitration case from Wikipedia:Requests for arbitration/Betacommand to Wikipedia:Requests for arbitration/Bot Policy. The reasons for this can be found out on my statement and the evidence presented by me. Thank you. --Parker007 01:48, 8 April 2007 (UTC)[reply]

Comment by Arbitrators:

Frankly, fiddling around with the case name this late in the process seems like a waste of time. Cases aren't limited in scope according to their names, so I can't see what the practical benefit would be here. Kirill Lokshin 02:07, 8 April 2007 (UTC)[reply]

Comment by parties:

I also oppose this. -- Chrislk02 (Chris Kreider) 03:04, 8 April 2007 (UTC)[reply]

Cases aren't limited in scope according to their names, so I can't see what the practical benefit would be here. That's fine, I just was expecting to be treated respectfully. --Parker007 06:35, 18 April 2007 (UTC)[reply]

Comment by others:

I stronly oppose this, there's more than just bot policy involved Ryanpostlethwaite contribs/talk 01:51, 8 April 2007 (UTC)[reply]

I agree with Kyrill on this. Clarity would not be aided. --Tony Sidaway 02:22, 8 April 2007 (UTC)[reply]

I oppose this too. —METS501 (talk) 02:29, 8 April 2007 (UTC)[reply]

To the best of my knowledge no case has ever been renamed after it was opened. The casename is just not that important. Newyorkbrad 02:33, 8 April 2007 (UTC)[reply]

Agree with Ryan, Betacommand went on several destructive editing sprees whose virulence was amplified by the use of bots but were sanctionable even if done completely by hand (think of the Richard Arthur Norton incident from a while back). This is a user conduct case, not that much a bot case, and only slightly an admin conduct case. 64.160.39.153 04:59, 9 April 2007 (UTC)[reply]

Motion - no rule that prevents a regular editor, from editing at his or her own pace

2) I move the following, "That this arbitration committee recognizes that according to section 5 - assisted bots from the Bot policy there is no rule that prevents a regular editor, from editing at his or her own pace." Sincerely, --Parker007 20:01, 8 April 2007 (UTC)[reply]

Comment by Arbitrators:

Comment by parties:

I need the laws of wikipedia to be decided by the elected judges of wikipedia, not by a group which has a conflict of interest. --Parker007 01:10, 15 April 2007 (UTC)[reply]

I am not "Hijacking" this case. I am bringing forth evidence. I am a participant in this case. And I request to be treated fairly. --Parker007 06:33, 18 April 2007 (UTC)[reply]

Even if I am doing it for my own purposes I have already shown that I was blocked. The reasons for this can be found out on my statement and the evidence presented by me. --Parker007 16:51, 18 April 2007 (UTC)[reply]

You are not, nor were you ever, a party to this case. "Hijack" (as mentioned above) is the right word for this. – Steel 23:43, 18 April 2007 (UTC)[reply]

You cannot post here, unless you want to become a participant in this case too. Please Move Your comment down at the bottom of the list Comments by Others, as you have reverted my edit which put you at the bottom of the list Comments by Others. Shame on you Steel.--Parker007 23:51, 18 April 2007 (UTC)[reply]

http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Betacommand#Involved_parties Until an Arbitrator takes it to Proposed Decision for a vote I cannot be removed as a party to this case. --Parker007 23:39, 18 April 2007 (UTC)[reply]

Comment by others:

Shouldn't this be a proposed principal? The concern here isn't just the pace at which the edits were done, it was also the mistake that were made whilst making the edits, I think this is unecessary Ryan Postlethwaite 16:58, 18 April 2007 (UTC)[reply]

Comment by others:

I have no opinion on whether this motion passes, and have high respect for Parker007, but I would like to point out that this motion may be for his own purposes. See Parker007's block log. —METS501 (talk) 20:40, 8 April 2007 (UTC)[reply]

As a matter of procedure, this should be presented as a regular proposal below, so that the arbitrators can consider including it, if they deem appropriate, in the final decision of the case. There is no need for it to be considered as a "motion," which is the designation for more immediate items that the arbitrators need to act upon during the case. It is also worth noting that when a similar issue arose in the Marudubshinki case, it was not acted on, with an arbitrator opining that this was a policy issue outside the scope of arbitration. Newyorkbrad 22:10, 8 April 2007 (UTC)[reply]

You should bring this up at Wikipedia talk:Bot policy and ask the Bot Approvals Group to clarify the policy. Thatcher131 22:14, 8 April 2007 (UTC)[reply]

The Arbitration Committee decides specific disputes between editors, in a way that hopefully recognizes principles that may be relied upon for guidance in the future. It is not a court and does not "decide the laws." Newyorkbrad 01:14, 15 April 2007 (UTC)[reply]

Furthermore the arbitration committee does not make policy, and proposed decisions which look like they are breaking new policy grounds often attract negative attention from the community or are rejected by the arbitrators. Thatcher131 05:08, 15 April 2007 (UTC)[reply]

I disagree about the conflict of interest in this matter, the BAG is supposed to be in part an enabler. However I doubt you need to ask BAG to clarify it, the real question is how do admins understand and apply our policies. That can be discussed on the admin noticeboard if you really don't know. If you believe that you have been mistreated you need to start dispute resolution of your own, if it can't be resolved in the earlier forms and is not a content issue, it maybe possible for you to raise your own request for arbitration, but that will examine all parties' conduct (your own included), you can't however hijack another arbcom case for your own "political" purposes. --pgk 08:42, 15 April 2007 (UTC)[reply]

Parker, even if arbcom did state what you wanted stated, the community can always change the bot policy. —— Eagle101 ^{Need help?} 15:19, 18 April 2007 (UTC)[reply]

Motion to dismiss Parker007

3) I move to remove all comments/post by Parker007. He has attempted to use the case for personal reasons.

Comment by Arbitrators:

I see no good reason for Parker02 to be included as a "party" to this case. In addition his contributions here seem somewhat tangential. Paul August ☎ 17:42, 18 April 2007 (UTC)[reply]

Comment by parties:

Proposed. Betacommand ^{(talk • contribs • Bot)} 17:31, 18 April 2007 (UTC)[reply]

I oppose this motion. Until a vote is made at /Proposed decision I am still a party in this case. --Parker007 23:42, 18 April 2007 (UTC)[reply]

And I would like to mention a quote ""Cases aren't limited in scope according to their names" from an Arbitrator. --Parker007 23:50, 18 April 2007 (UTC)[reply]

I'm not at all sure Parker007 understands just what he is getting into in becoming a party to an arbcom case. I'd like to cite the recent case Wikipedia:Requests for arbitration/Billy Ego-Sandstein, where Billy Ego proposed a case, had it roundly rejected, kept pressing the point until it was accepted, and ended up being banned for a year in a fairly short deliberation. The arbcom are 14 of the busiest people on the Wikipedia, it is downright perilous to annoy them unnecessarily; they are also 14 of the most experienced editors on the Wikipedia, and if they devote their energies to it, they will find every skeleton in every closet. Being a party to an arbcom case is not at all a safe thing, and I strongly advise participating with that in mind. --AnonEMouse ^(squeak) 19:45, 19 April 2007 (UTC)[reply]

Comment by others:

Support, there seams to be a clear conflict of interest here. Ryan Postlethwaite 17:36, 18 April 2007 (UTC)[reply]

Support as somone familliar with Parker and the way he acts. – Steel 23:44, 18 April 2007 (UTC)[reply]

I agree as well. 71.183.106.162 23:28, 20 April 2007 (UTC)[reply]

Proposed temporary injunctions

Template

1)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

2)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

3)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

4)

Comment by Arbitrators:

Comment by parties:

Comment by others:

Questions to the parties

Proposed final decision

Proposed principles

Administrators

1) Wikipedia administrators are trusted members of the community and are expected to follow Wikipedia's policies and guidelines. Occasional lapses of judgment are tolerated, but consistently poor judgement may result in desysopping.

Comment by Arbitrators:

Yes. Paul August ☎ 19:12, 19 April 2007 (UTC)[reply]

Comment by parties:

Agree with Tony Ryanpostlethwaite contribs/talk 01:46, 30 March 2007 (UTC)[reply]

Comment by others:

Proposed. Adapted from the Konstable arbitration. --Tony Sidaway 01:43, 30 March 2007 (UTC)[reply]

Common sense. Durova^Charge! 00:59, 2 April 2007 (UTC)[reply]
Well sure; I don't understand what the proposal is aiming at though. Betacommand has unquestionably exhibited consistently poor judgement, yet the desysopping proposal further down has no strong supporters and some strong opposers. 64.160.39.153 06:25, 13 April 2007 (UTC)[reply]

Username blocks

2) Username blocks should only be made if there is a blatant infringement of the Username policy, community input should be sought otherwise.

2.1) If a username was obviously chosen in bad faith, or if a username is so problematic that it should never appear in article histories (e.g. a very offensive username), then admins may block it on sight. Admins should not block usernames that may have been chosen in good faith.

Comment by Arbitrators:

The last sentence of 2.1 is problematic. I don't think we want to allow the username "IHateJews" even if it had "been chosen in good faith". Paul August ☎ 02:35, 4 April 2007 (UTC)[reply]

Agree with Paul. A dyed-in-the-wool anti-Semite will take said username in good faith, but that good faith is opposed to Wikipedia policies. In such a situation, the intent of the user is frankly irrelevant. Mackensen (talk) 02:57, 4 April 2007 (UTC)[reply]

Comment by parties:

Proposed Ryanpostlethwaite contribs/talk 01:40, 30 March 2007 (UTC)[reply]

Comment by others:

Expanded abbreviation. No comment as yet. --Tony Sidaway 01:45, 30 March 2007 (UTC)[reply]

2.1 is adapted from the blocking section of the username policy page. --Tony Sidaway 02:43, 30 March 2007 (UTC)[reply]

Sensible. Close calls about username blocks shouldn't be unilateral actions since mistakes have far-reaching consequences: a well-meaning editor gets who indef blocked at the outset may never return. Durova^Charge! 00:58, 2 April 2007 (UTC)[reply]

2.1 isn't ideal, it isn't always easy to judge if the user was choosing in good faith or not, and that can lead to it's own arguments. Really I think this is a broader community issue as to what is/isn't acceptable regarding usernames and blocking, as for most things instruction creep particular that which just adds vague rules which can be interpreted numerous ways aren't necessarily that useful. --pgk 06:14, 4 April 2007 (UTC)[reply]

Instruction creep. Best just to say, don't block usernames unless there is really good reason to do so.--Doc^g 23:07, 5 April 2007 (UTC)[reply]

I'd rather ditch both versions. Some of those username blocks were inappropriate but I don't think arbcom needs to go around upholding a right to select any username that doesn't reach some high level of offensiveness. The idea of user accounts and usernames is to help the encyclopedia and bending over to defend annoying usernames doesn't seem that helpful. Some of us get by just fine without using a username at all. More at issue is the manner of the blocks and the refusal to heed the requests of other admins to stop the nonsense. I'd express the principle as: seek consensus for questionable cases. 64.160.39.153 06:17, 10 April 2007 (UTC)[reply]

'Good faith' is a judgment call. This doesn't have a lot to do with this case, because it is about how that there was never any judgment at all due to the use of bots. There has been little discussion (in the case) about whether the blocks were right or not, because it's not the issue. The issue is that if you block 100 good users in a short time, even when you also block a 1000 bad ones, it's a problem. Especially if they are new users. Tinus 21:32, 11 April 2007 (UTC)[reply]

I'm no expert on username blocks, but just from looking at the username policy I can see that only clearly inappropriate names may be blocked on sight by an administrator. Borderline names, questionable names, or names made in good faith (other than extremely problematic ones) should always be discussed at WP:RFC/NAME. Pyrospirit ^{Flames Fire} 02:05, 14 April 2007 (UTC)[reply]

Bots

3) Bots are fully automated Wikipedia accounts capable of performing preprogrammed actions without the individual authorization of each action by the owner. Users may apply to run a bot at Wikipedia:Bots/Requests for approval and must operate only authorized bots and always within Bot policy.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. I don't think we've had this before. The definition of a bot may need some work. --Tony Sidaway 01:56, 30 March 2007 (UTC)[reply]

I think I read through an old one, involving some user doing bot deletions that got him desysopped. Milto LOL pia 08:37, 30 March 2007 (UTC)[reply]

Again, common sense and well established. Durova^Charge! 00:59, 2 April 2007 (UTC)[reply]
Oppose on multiple grounds.

Technical: 1) bots are programs, not Wikipedia accounts; 2) bots whose "preprogrammed actions" don't involve editing (e.g. crawlers) have generally not needed authorization if they don't send too many hits too fast; 3) a lot of these problematic edits were from scripts where Betacommand had to approve each edit and which therefore don't qualify as bots under the proposed definition. The problem is not about bots but about Betacommand's terrible judgement in deciding what kinds of edits to perform (with a bot or otherwise).
Matthews' law: trying to make legalistic definitions of what bots are simply creates yet another boundary for idiots to press against as hard as they can without crossing it. Better to just say Wikipedia is a human-edited encyclopedia and automated tools of any type should be used with care and with deference to consensus, currently via BAG.
Jurisdictional: I don't think defining bots and bot policy is the right thing for arbcom to be doing at this point. I don't think there should be much bot policy beyond a sense that bot users and developers really better know what they're doing and act responsibly, even more than admins. Writing and running a bot or script can be almost like checking code into the MediaWiki SVN, something normally done only by highly trusted and normally sensible people, in terms of the wide-scale effects it can have. That includes deploying things like VandalProof, which is not a bot at all by most definitions. If there really does have to be more technical policy developed about this stuff, it should be done by BAG with possible input from the MediaWiki developers. 64.160.39.153 06:43, 10 April 2007 (UTC)[reply]

Automated editing

3.1) Various tools exist to partially or fully automate repetitive editing tasks. The Wikipedia:Bots/Approvals group (BAG) recognizes three types of bots:

Unsupervised automatic - User runs a bot without being in its presence
Supervised automatic - User runs a bot and watches the edits, but does not have to interact directly
Manually-assisted - User must confirm every change manually

Additionally, editors may use scripts to assist in performing repetitive edits. Generally, scripts require manual confirmation of each edit. Unsupervised and supervised automatic bots require approval of the BAG. Manually assisted bots and scripts may require approval if the editor anticipates making high speed edits.

Comment by Arbitrators:

Yes. Paul August ☎ 19:13, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Replacement for #3. I have also refactored some other bot-related proposals below to flow together with this. Thatcher131 23:04, 2 April 2007 (UTC)[reply]

Responsibility for automated and semi-automated actions

3.2) An editor is accountable for all edits, blocks, deletions, or any other logged action or change under their control. Disruptive actions undertaken by automated or semi-automated tools are the editor's responsibility, including ensuring that the tool functions properly and that the edits are appropriate and fully authorised.

Comment by Arbitrators:

Comment by parties:

Comment by others:

I don't know who proposed this, but I prefer it to my own proposals 4 and 5, which get bogged down in the morass of bot policy. --Tony Sidaway 16:45, 30 March 2007 (UTC)[reply]

Reworded slightly. I think we can do away entirely with principles 3, 4, and 5. The definition and rules for using the tools should be left to others. Editing responsibly and responding appropriately to concerns is vital no matter how the edits are made. Thatcher131 16:51, 30 March 2007 (UTC)[reply]

Sweet, now I feel helpful. I proposed this but didn't have any opinion and am not a aprty, so I didn't leave a comment. Should I sign these when I make new ones so people know who drew them up, or does it matter? Milto LOL pia 17:00, 30 March 2007 (UTC)[reply]

Yes, you should sign your proposals. Thatcher131 17:03, 30 March 2007 (UTC)[reply]

Added "and fully authorised" to the responsibilities of the user. --Tony Sidaway 17:27, 30 March 2007 (UTC)[reply]

Frankly any of the choices that cover this ground are fine with me. Durova^Charge! 01:02, 2 April 2007 (UTC)[reply]

Access to automated editing tools

3.3) An editor who misuses automated editing tools such as bots and scripts, or fails to respond appropriately to concerns about their use, may lose the privilege of using such tools.

Comment by Arbitrators:

Yes. Paul August ☎ 19:14, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Prop. Thatcher131 16:51, 30 March 2007 (UTC)[reply]

Yes. --Tony Sidaway 17:28, 30 March 2007 (UTC)[reply]

Agreed. Durova^Charge! 01:03, 2 April 2007 (UTC)[reply]
Is this enforceable? --Doc^g 23:08, 5 April 2007 (UTC)[reply]

Yes, by blocking. See here. Thatcher131 17:19, 6 April 2007 (UTC)[reply]

And access can be restricted less harshly in certain tools, such as AWB, VP and NPW, by removing a name from the approvals list. Mart inp23 14:27, 15 April 2007 (UTC)[reply]

Admin bots

3.4) ~~There is strong community opposition to running bots on sysop accounts and especially to equipping bots to perform deletions and other sysop functions.~~

3.4 Admins should not run bots on their sysop account that are enabled to perform sysop actions (blocking, deleting, etc) without specific community approval from Wikipedia:Bots/Requests for approval and/or WP:RFA.

Comment by Arbitrators:

There are two different issues here, and I'm not sure, as above, that the first case is proved (Curps being one example). For the second, we have the ProtectionBot RfA. Mackensen (talk) 00:05, 3 April 2007 (UTC)[reply]

Yes to the reworded version. Paul August ☎ 19:18, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Prop. Thatcher131 23:47, 2 April 2007 (UTC)[reply]

I strongly disagree. There isn't community opposition to adminbots. ProtectionBot RFA would have passed, and many of the opposes there were because it could be better done in MediaWiki and that it wasn't open source. Take an open sourced adminbot that fulfills a necessary function that MediaWiki cannot and I think easily 90% of the community would support it. There's no way that the majority of the community opposes adminbots, and it would be foolish for ArbCom to say so when it clearly isn't the case. --Cyde Weys 00:44, 3 April 2007 (UTC)[reply]

Reworded. I'm not sure at this point whether Betacommand's high speed blocking was done by manually assisted script or bot. It may not make a difference. Thatcher131 01:05, 3 April 2007 (UTC)[reply]

The reworded version is much better. Thanks. --Cyde Weys 12:41, 3 April 2007 (UTC)[reply]

I also support the reworded version. —METS501 (talk) 16:13, 3 April 2007 (UTC)[reply]

Looks good, but it might be a good idea to clarify when it is "ok" to run a bot/script under your own account, and when it is needed to take the bot to RFA (where if I use the last Bot RFA as a guideline) it has a decent chance of getting approved. I think any automated process should operate under its own username, thats pretty much a standard for automated processes. I'm not so sure if a BRFA is quite the right place to ask for sysop approval, thats RFA's place, to put it more clearly I think it is a community issue when we speak of sysoping bots, and I don't think having it in the hands of 10 or so BAG members is a good thing. BAG is good for technical details, but as far as passing out admin bits, that should be left up to a wider community discussion, with a B-crat closing. —— Eagle101 ^{Need help?} 17:20, 3 April 2007 (UTC)[reply]

There's no way of simply and effectively getting an adminbot authorised and it's little wonder some users are using their admin accounts to run bots and semi automated scripts. The ArbCom needs to start the ball rolling on how adminbot accounts are handed out. -- Nick^t 17:26, 3 April 2007 (UTC)[reply]

I don't know if that is within ARBCOM's remit :). But yes, adminbots are either going to have to pass RFA (which seems doable judging from the last one which would have passed had Werdna not made the mediawiki improvement.), or a new process is going to have to be set up. I am leaning towards the former right now, but in any case it needs to be something where the whole community can voice their concerns with. I do think that BAG may be able to play a role, but mainly as technical advisors... though they can do that without having the official nature of "bag" member, after all any bot programmer knows what it takes to make a good bot, but to do that it requires that anyone can view the source. I don't think there is much harm in that as only an admin can run the code in any case. —— Eagle101 ^{Need help?} 18:00, 3 April 2007 (UTC)[reply]

If I recall correctly, the reason ProtectionBot was not open-sourced was a form of security through obscurity, i.e. to prevent vandals from finding holes in it. While I think this was silly regardless, I speculate that it wouldn't even be a perceived issue in most cases. I do agree that it's important that bots, especially admin bots to be fully disclosed (which is orthogonal to open-source. someone can GPL it and never publically release it, or show us all the source but have a restrictive copyright license. While open-source may be important ideologically to most all of us, disclosure is equally important in this case from a community point of view.) --Random832 20:52, 4 April 2007 (UTC)[reply]

Approval for high speed automated edits

3.5) Editors who wish to use semi-automated tools for high speed editing are advised to seek the approval of the BAG. The Bot policy advises that assisted bots may need to be run under a separate account if many edits are going to be made and may need a bot flag if rapid editing is proposed. "If you have any doubts, it is safer to go through the approval process."

Comment by Arbitrators:

Yes. Paul August ☎ 19:18, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

New/alternate version. This describes current practice as best as I can tell. I don't think Betacommand ran an admin bot, but rather he edited with bot-like speed from his main account under unclear circumstances. ArbCom should not set bot policy, that should be left to the community. ArbCom can clarify what seems to be current consensus, which is what I have tried to do here. Thatcher131 17:53, 3 April 2007 (UTC)[reply]

I like the looks of this one. —— Eagle101 ^{Need help?} 18:03, 3 April 2007 (UTC)[reply]

Editors who Wish to use Semi-Automated Tools for High Speed Editing who pass 5 Edits per Minute Must seek A Bot Flag, without the nessecity of creating a seperate Bot account

3.7) Editors who Wish to use Semi-Automated Tools for High Speed Editing who pass 5 Edits per Minute Must seek A Bot Flag, without the nessecity of creating a seperate Bot account

Comment by Arbitrators:

I share the reservations expressed below. Paul August ☎ 14:56, 3 May 2007 (UTC)[reply]

Comment by parties:

Proposed. --Parker007 11:27, 28 April 2007 (UTC)[reply]

Would lead to a dangerous side effect - being blocked without discussion. When a person makes a questionable edit or series of edits, we discuss. When a bot does it ... WP:BOT: "An admin can block on sight any bot that appears to be out of control." --AnonEMouse ^(squeak) 14:00, 1 May 2007 (UTC)[reply]

Comment by others:

You mean you want a bot flag on your ordinary account? That strikes me as a bad idea. Christopher Parham (talk) 19:33, 28 April 2007 (UTC)[reply]

Bad idea unless I misunderstand what a bot flag does (hmm, looks poorly documented at WP:BOTS and I don't feel like digging through SVN to figure it out). I thought the idea was to keep uninteresting bot edits from showing up in RC. If you WANT the edits to show up (some types of bot edits should have human review) then they should NOT be made under a bot flag. For example, a mass link removal (including legitimate ones done by consensus) should not done under a bot flag. It should instead done unflagged (even if fully automated), leaving edit summaries requesting review of the edit and inviting reversion if the editor or bot made an error. Also agree with Christopher Parham, only bot edits should ever be bot-flagged. The bot flag means the specific editing task has been pre-reviewed through the bot approval process. The approval isn't just about editing speed, it's about the nature of the actual edits. Semi-automated editing is less likely to have had pre-review and should therefore not be bot-flagged. 75.62.7.22 20:18, 28 April 2007 (UTC)[reply]

Removal of bot privileges

4) The onus is on the owner of a bot to demonstrate that he or she is running it in accordance with all relevant policies and in a manner that is beneficial to Wikipedia. If a user fails to satisfy the community that he or she is doing so, the community may remove the authorization, through the Bot approvals group or as a result of the Dispute resolution process.

4.1) The onus is on the owner of a bot to demonstrate that the bot is harmless, is useful, is not a server hog, has been approved, and abides by all guidelines, policies and common practices. If a user fails to satisfy the community that he or she is doing so, the community may remove the authorization, through the Bot approvals group or as a result of the Dispute resolution process.

Comment by Arbitrators:

Comment by parties:

Already done and BAG has taken care of it. Betacommand ^{(talk • contribs • Bot)} 17:54, 18 April 2007 (UTC)[reply]

Comment by others:

Proposed. Based on Bot policy and existing dispute resolution apparatus (the arbitration committee is authorized to revoke bot approvals, for instance). --Tony Sidaway 02:03, 30 March 2007 (UTC)[reply]

4.1 is a variant that adopts the language of the current Bot policy. --Tony Sidaway 02:13, 30 March 2007 (UTC)[reply]

I like this. It shifts the discussion onto the appropriate ground. Durova^Charge! 01:01, 2 April 2007 (UTC)[reply]

Replaced by 3.1 through 3.3. Thatcher131 23:04, 2 April 2007 (UTC)[reply]

Semi-automatic scripts

5) Various semi-automatic scripts are used, some widely distributed and some written by the operator. These scripts enable preprogrammed Wikipedia operations to be performed ~~at high speed,~~ while the user is in constant attendance and makes the final decision for each individual operation. While specific authorization is not required to run a script, the onus is on the user to demonstrate that he operates the script in accordance with all Wikipedia policies and in the interests of Wikipedia.

Comment by Arbitrators:

I'm not convinced that we need to weigh in on this. You have to be prepared to defend an edit regardless of the method. Mackensen (talk) 11:04, 2 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed. This extends the relevant principles of the bot policy to attended scripts. It's my understanding that Betacommand runs a bot but has also performed rapid blocks via some kind of IRC-based semi-automatic script. --Tony Sidaway 02:50, 30 March 2007 (UTC)[reply]

Currently BAG uses the following terms:

Unsupervised automatic - User runs a bot without being in its presence
Supervised automatic - User runs a bot and watches the edits, but does not have to interact directly
Manually-assisted - User must confirm every change manually

I just want to be careful of the wording of this type of proposal. There are grey areas between each level, but in general BAG only regulates the first two, however, a manually-assisted bot must be implemented in a fashion that provides it with enough information perform the edit. For example, a manually-assisted bot that finds a spelling mistake and confirms replacement without showing proper context would not be approved under bot policy even though it is manually-assisted. This is why the bot policy reads "Assisted bots don't necessarily need bot approval" because some manually assisted bots do need it, although most do not.

High speed editing (with "large" quantity of edits) always requires approval because it is disruptive to recent changes users and a bot flag is required in these cases. When in doubt, a user should seek approval, because a user can be blocked without notice for perceived violation of bot policy. This is typically due to editing too quickly or a user not providing enough information in edit summaries or on their user pages describing what a bot is doing.

With the introduction of various scripts, the line between bot and user has become unclear. Betacommand's script was in violation of bot policy because of editing speed, but was it in violation of bot policy because it was a semi-automated script? Was it in violation in cases where used as a semi-automated admin script? This is what I'd like to see a proposal deal with if possible. *IF* Betacommand's script did not provide enough context to perform the edit reliably (I have not seen the source code), then should it be treated as an automated bot?

More importantly, does the Wikipedia community feel that script development, automated or manual, should be regulated by BAG (or someone else) to ensure accuracy? Some manually assisted bots are performing trivial and/or uncontroversial tasks and BAG does not want to deal with those requests if possible, but there is a compelling argument to be made that there should be oversight over manual scripts for non-trivial or potentially controversial tasks. Such oversight is in the interest of Wikipedia. While BAG will process these requests, I don't think anyone has sought consensus on this issue or a ruling from arb-com as to whether this is required. -- Ram-Man 14:55, 30 March 2007 (UTC)[reply]

Do you really want ArbCom to rule on this? Or would it be better to approach the community? Certainly editors are responsible for all their edits, whether made by a fully automated software tool or assisted by a semi-automated tool, and editors who show poor judgement may have their use of tools restricted just as editors who show poor judgement in making manual edits may find themselves under parole or probation. But questions such as, "How fast may an assisted script edit without a bot flag" or "Should admins be allowed to use assisted deletion or blocking scripts and if so, how should such use be governed" seem beyond the scope of the arbitration process. Thatcher131 16:26, 30 March 2007 (UTC)[reply]

See my comments below, however, I wouldn't mind if ArbCom ruled on something: That all admin scripts must be approved under bot policy (or similar). I believe this to be the clear community consensus, however, there is some confusion over this issue. -- RM 17:53, 30 March 2007 (UTC)[reply]

My proposal has some serious flaws, which I think Ram-Man has exposed. What I'm trying to do is extend the principles of bot policy (that the onus is on the editor) to scripts. I think I should reword to remove the phrase "at high speed" because in my mind speed of operation isn't the issue. --Tony Sidaway 16:38, 30 March 2007 (UTC)[reply]

I'm not sure if I want ArbCom to rule on this. Afterall, bot policy is working fine with very few problems and additional rulings could just interfere. Plus wider community input is more useful. I just want to make sure that ArbCom doesn't rule in such a way to make bot approvals a miserable experience for all parties involved. My specific problem with this proposal is that for "semi-automatic scripts...specific authorization is not required". I think that usage of the term "automatic" is unclear and more importantly that BAG DOES sometimes require approval for such bots/scripts, especially admin functions. If ArbCom accepted this proposal, it would impose additional limits the power of the BAG, which is the key oversight of bots and scripts. Tony Sidaway has stated his intent to "extend the principles of bot policy", but that is not how I read this proposal. -- RM 17:15, 30 March 2007 (UTC)[reply]

Oppose as generally per my opposition to the proposed bot definition further up. I appreciate Tony Sidaway's good intentions but I think these proposals cause more problems than they solve. 64.160.39.153 07:12, 10 April 2007 (UTC)[reply]

Assume good faith is also applicable to admin actions

6) Some of the username blocks are based upon events current at the time of blocking. e.g. creation of multiple similar names used for vandalism or pages created and deleted. Admins cannot always remember all the details all the time, unless there is evidence to the contrary Assume good faith should apply.

Comment by Arbitrators:

Comment by parties:

I certainly agree with the title, but the body section is vague, and hard to understand. Can you restate more specifically than "specific to given events at given time"? I'm not at all sure what you're trying to express. --AnonEMouse ^(squeak) 14:36, 30 March 2007 (UTC)[reply]

I've tried to update it, though I'm not sure which part you find unclear. If we have 20 very similar names being created and the first 19 all do vandalism, blocking the 20th before it gets chance to vandalise is not unreasonable. Being asked why you blocked that apparently innocuous name 2 months later may be difficult. --pgk 15:42, 30 March 2007 (UTC)[reply]

Thanks, the rewrite is an improvement, I understand now. --AnonEMouse ^(squeak) 17:05, 30 March 2007 (UTC)[reply]

Comment by others:

Proposed --pgk 13:51, 30 March 2007 (UTC)[reply]

I agree with this, but we should only assume good faith by the admin, if the admin assumed good faith when blocking. I would strongly support this if Betacommand can show further evidence that these blocks were infact correct Ryanpostlethwaite 15:51, 30 March 2007 (UTC)[reply]

I will dig though my blocklog and attempt to remember/gather evidence but please keep in mind that I dont keep records of why I blocked. and that this occurred over a month ago and the rule when fighting vandals is Revert, Block, Ignore. and the only reason that the fatterwhales sticks out is because there was a RFCN and a SSPA case, along with a note on my talkpage Betacommand 15:58, 30 March 2007 (UTC)[reply]

PS another case in which my block was over turned and re-blocked [1]

Not sure pointing them out helps much. If I blocked randomly for the next 100 users created and some got unblocked, I'm sure some of those too would turn out to be trolls/vandals/socks etc. but the block wouldn't be indicative of any particular good judgement on my part --pgk 19:12, 30 March 2007 (UTC)[reply]

These are not random blocks, Im gathering data to show some patterns that I observed and blocked for in Feb. And Ryan also asked for more evidence. Betacommand ^{(talk • contribs • Bot)} 19:17, 30 March 2007 (UTC)[reply]

This should be trimmed somewhat if it's a proposed principle. It contains some elements of a finding. --Tony Sidaway 16:32, 30 March 2007 (UTC)[reply]

On viewing Pgk's explanation, I think the underlying problem here is failure to annotate administrator actions adequately. If an admin himself can't work out why he made a block a few months ago, then that means Wikipedia itself has no knowledge of the circumstances of the block. We assume good faith, but that doesn't mean it's okay to make administrator actions with empty or inadequate summaries. --Tony Sidaway 17:20, 30 March 2007 (UTC)[reply]

Well I think they'd say it was blocked for the reason in the block log, the precise detail maybe somewhat lost. It is probably somewhat the nature of the beast when things you are involved in a large number of actions (be that blocks, deletions, page protections etc.). I'm sure I can dig through many an admins block log and find entries just listing "sock of x", just "sock" or even "sock of someone" based on behaviour apparent at the time, not many admins will be documenting their precise reasoning. --pgk 17:28, 30 March 2007 (UTC)[reply]

Needs rewording for clarity. I like the basic idea: it's a disturbing fact that frequently, when one or more respected editors come to the defense of some person, they allege bad faith on the part of the acting sysop. We get accustomed to disregarding this kind of thing when it comes from trolls. Regular Wikipedians do it on a more sophisticated level: i.e. hasty allegations that a block was punitive (and hence shouldn't have been implemented) without asking the sysop what the reasons were - or even repeating allegations of punitive action after the sysop has supplied cogent and legitimate reasons. Part of Assume good faith has to mean that we attribute the best motivations regarding sysop decisions. Durova^Charge! 01:14, 2 April 2007 (UTC)[reply]

Nah. "Assume Good Faith" must be the most oft-cited, misused, misremembered, misapplied, and most often sprinkled term in a dispute. I so, so, so recommend folks read the policy again. It's about edits. When it comes to pressing the hot button of "block," one had better not rely upon assumptions. We should be ready to explain our actions. If a person is "too busy" to explain, then that person is too busy to be blocking. Blocks are not normal. They are extraordinary, and treating them as "ho-hum, I'm sure I had a good reason" should in no way be encouraged nor tolerated. Geogre 04:08, 14 April 2007 (UTC)[reply]

Communication

7) Proper communication is extremely important for every editor, especially administrators. Due to collaborative nature of Wikipedia, users are expected to respond to messages intended for them and to constructively discuss controversial issues.

7.1) Due to the collaborative nature of Wikipedia, proper communication is extremely important, and all editors are expected to respond to messages intended for them in a timely manner and to constructively discuss controversial issues. This is especially true for administrators in regard to administrative actions. Such expected communication includes: giving appropriate (as guided by Wikipedia's policies and guidelines) warnings prior to, and notification messages following, their actions; using accurate and descriptive edit and administrative action summaries; and responding promptly and fully to all good faith concerns raised about their administrative actions.

Comment by Arbitrators:

I've proposed a new version 7.1 of this principle, which incorporates ideas and language from principle 10 below. Paul August ☎ 20:04, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed. IMHO, this is the key problem in this affair. MaxSem 14:30, 1 April 2007 (UTC)[reply]

I agree. --Tony Sidaway 16:49, 1 April 2007 (UTC)[reply]

I agree too. I also reworded it a tiny bit. —METS501 (talk) 16:54, 1 April 2007 (UTC)[reply]

Certainly Ryanpostlethwaite contribs/talk 16:55, 1 April 2007 (UTC)[reply]

Agreed. Durova^Charge! 01:15, 2 April 2007 (UTC)[reply]

Yes. —— Eagle101 ^{Need help?} 20:50, 2 April 2007 (UTC)[reply]

Me too. 64.160.39.153 04:44, 11 April 2007 (UTC)[reply]

Questioning of administrators blocks

9) If there is concern raised over an administrators block, the admin in question should first be contacted. If this fails to solve the issue, a comment should be placed on an appropriate administrative noticeboard.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed Ryanpostlethwaite contribs/talk 21:37, 5 April 2007 (UTC)[reply]

Em, not quite. If an admin blocks an established user in controversial circumstances- a very quick review may be required. If there is no immediate response to a note on the admin's talk page (and I mean immediate), it seems reasonable to take it straight to ANI - and inform the admin that you've done so.--Doc^g 23:12, 5 April 2007 (UTC)[reply]

I assume you mean like in 5 minutes or so... ;) —— Eagle101 ^{Need help?} 23:41, 5 April 2007 (UTC)[reply]

Actually something like that. If an admin deletes something, it is reasonable to give him 48 hours to explain why, or reconsider, before running publicly to DRV - generally nothing is lost by having no article for a while (although there are exceptions). But when an established wikipedian is blocked, tempers rise very quickly. It is best that such be immediately reviewed and bad calls speedily reversed - waiting even eight hours while the blocking admin sleeps is not going to cut it. Give the blocker just long enough so that if he's still actively on-line he has a moment to consider reversing himself without a public ho-ha, and then go straight to ANI.--Doc^g 17:07, 6 April 2007 (UTC)[reply]

Agree completely with Doc. Few things are ever a "Wikipedia emergency", but a questionable block can stir up huge controversy in a hurry, and a speedy review may help prevent this. Friday (talk) 17:15, 6 April 2007 (UTC)[reply]

Right, but care does need to be given to give the blocking admin a chance to see that orange bar. 5-10 minutes ought to be enough to give the admin a chance to say I'm still active, and figure out if he wants to unblock or not. Needless to say, if you block an established user based on iffy rational you really ought to post to ANI or AN anyway... or consider that blocking is not the best solution. Though I don't think betacommand has blocked any established users in quite some time. —— Eagle101 ^{Need help?} 20:27, 6 April 2007 (UTC)[reply]

Seems to be covered by WP:BLOCK#Controversial blocks, as something ripe for review before blocking on WP:AN/I, a listing in short order should be a non-issue assuming you've given a reasonable time for the blocking admin to list it up themself. --pgk 09:40, 7 April 2007 (UTC)[reply]

Communication between administrators and subjects of administrative action

10) Proper communication between administrators and other editors is extremely important when an administrator takes action against a non-admin. The administrator, as appropriate for the specific action, should leave a proper message on the user's talkpage, create an accurate edit summary, interact with the editor civilly, and respond swiftly to talkpage messages from the editor.

Comment by Arbitrators:

These are important points, I've incorporated them into principle 7.1 above. Paul August ☎ 20:04, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed. There may be better wording, and there may be more than one principle here, but the general idea that experienced and en-tooled or em-powered users must explain themselves as they take admin action and after they take admin action, this idea needs to be expressed. Jd2718 02:55, 18 April 2007 (UTC)[reply]

Blocking

11) Blocking is a serious matter. Administrators should be exceedingly careful when blocking. Blocks should be made only if other means are not likely to be effective; prior discussion or warnings, should generally precede all blocks. Blocks should be used only to prevent damage or disruption to Wikipedia, and if there could be any reasonable doubt about whether a block is appropriate, other administrator should be consulted at WP:ANI. Following a block the blocked editor should be notified of the block on their talk page, and additional notification may be appropriate at WP:ANI.

Comment by Arbitrators:

Proposed. Paul August ☎ 15:40, 22 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

I wholeheartedly endorse this principle. Betacommand's scandalous block of Irpen was a slap in the face of the community and contributed to my departure from English Wikipedia. It's very frustrating to see so many admins who ignore the basics of our blocking policy. They should be desysopped promptly and vigorously. --Ghirla ^-трёп- 12:33, 23 April 2007 (UTC)[reply]

Template

12) {text of proposed principle}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed findings of fact

Betacommand

1) Betacommand (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) is an administrator with expertise in the authoring and running of bots and scripts, and was a member of the Bot approval group (BAG) until voluntarily stepping aside 23 March 2007.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

"voluntarily stepping aside" is airbrushing it a bit: see the last two subsections of BAG discussion here. Xeriphas1994 23:26, 24 April 2007 (UTC)[reply]

Betacommandbot

2) BetacommandBot (talk · contribs · deleted contribs · logs · filter log · block user · block log) is a bot account operated by Betacommand. It originally performed category maintenance tasks and added Wikiproject templates to article talk pages. On 21 March 2007 it received approval to compile lists of articles containing suspected spam external links. See Wikipedia:Bots/Requests_for_approval/BetacommandBot, Wikipedia:Bots/Requests_for_approval/BetacommandBot_2, and Wikipedia:Bots/Requests_for_approval/BetacommandBot_3.

Comment by Arbitrators:

Comment by parties:

Comment by others:

I may need some help here to determine what the bot was approved to do and what it wasn't. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

Allegations

3) The ~~loci of dispute~~ allegations in this case are that 1) Betacommand inappropriately blocked accounts for violations of the Username policy; 2) that Betacommand inappropriately and indiscriminantly removed external links identified as spam; and 3) that Betacommand blocked an editor with whom he was involved in a content dispute.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

In general, I think your drafting here is unclear--for instance is the committee intended to find here that Betacommand's link removals were, in fact, "inappropriate and indiscriminate"? If so, does the evidence support this? If not, then the finding needs to be reworded. I don't understand point (3) at all. In what way was Betacommand involved in a content dispute?--Tony Sidaway 02:02, 3 April 2007 (UTC)[reply]

They are the allegations of the filers (reworded thusly). Without specifying the allegations, the proposals that were first placed here had no context. I personally do not believe the Pallywood allegation has merit, as noted below, but it was mentioned on the noticeboard as a reason for desysopping. Thatcher131 02:11, 3 April 2007 (UTC)[reply]

Then my problem here is only that your framing of the dispute looks like a series of statements of fact about Betacommand's conduct, rather than a series of contentions made by the disputants about his conduct. --02:18, 3 April 2007 (UTC)

I struck "loci of dispute" and replaced it with "allegations", feel free to reword it further if needed. Thatcher131 02:24, 3 April 2007 (UTC)[reply]

Betacommand's username blocks

4) Betacommand's blocks for violations of username policy have attracted complaints on multiple occasions. [2] [3] A number of Betacommand's username blocks have been overturned (see here). After complaints about his username blocks on 18 February 2007 and following, Betacommand began using an automated tool ~~to flood WP:RFCN with reports~~ that made numerous reports to WP:RFCN. [4] [5]. Betacommand was blocked by Pschemp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) for using an unauthorized bot and was unblocked 12 minutes later by Wangi (talk · contribs · blocks · protections · deletions · page moves · rights · RfA).

Comment by Arbitrators:

I have proposed 4.5.1 through 4.5.4 below, as reformulated and reorganized alternatives to this and other "4" findings of fact. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

Yeah he did have some problems with this, but I also think this is an older issue, as Betacommand has curbed the number of username blocks that he has issued, and there have been no problems that I have seen in the last 2-3 weeks or so. —— Eagle101 ^{Need help?} 17:28, 3 April 2007 (UTC)[reply]

I'm not sure about the word "flood" - it seems like a word that is carefully engineered for its overtones in this finding. I'd prefer another word, though I can't suggest one. Perhaps "...Betacommand began using an automated tools that placed numerous reports on WP:RFCN"? Flood seems prejudicial to me. Philippe 07:11, 6 April 2007 (UTC)[reply]

Good point. Thatcher131 16:18, 7 April 2007 (UTC)[reply]

Betacommand used a bot to disrupt Wikipedia

4.1) Betacommand disrupted Wikipedia ~~to make a point~~ by ~~flooding~~ reporting large numbers of obvious username violations to Wikipedia:Requests for comment/User names, and later repeating the same behavior at WP:AIV, See Wikipedia:Requests_for_arbitration/Betacommand/Evidence#Username_blocks_-_Community_involvement.

Comment by Arbitrators:

I have proposed 4.5.1 through 4.5.4 below, as reformulated and reorganized alternatives to this and other "4" findings of fact. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

I agree with this. Betacommand was also blocked for "(refuses to stop bot reporting with this account)" during this time. -- Chrislk02 (Chris Kreider) 13:23, 3 April 2007 (UTC)[reply]

I never used a bot to disrupt AIV, I just reported username blocks that I would have placed, Due to the Username block discussions I have stopped blocking username vio's. So since I had stopped username blocking I did what admins did. I reported them to AIV.

And the RFCN I did auto report some after complaints were brought to my attention. pschimp asked me to stop, I then disabled auto RFCN reporting. later I found a error in my code and restarted it. At that time RFCN was enabled again by mistake, and I did not catch it. Betacommand ^{(talk • contribs • Bot)} 18:08, 18 April 2007 (UTC)[reply]

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

I would insert "After concerns were raised about his username blocks," at the beginning of the sentence to establish the context. Newyorkbrad 16:47, 3 April 2007 (UTC)[reply]

"To make a point" is superfluous here. His purpose for disrupting is immaterial. I've removed the ugly bit of gibberish, "WP:POINT", and replaced it with "Betacommand used a bot to disrupt Wikipedia". I've struck out "to make a point." --Tony Sidaway 22:09, 3 April 2007 (UTC)[reply]

removed the word "flood" per above. Thatcher131 16:19, 7 April 2007 (UTC)[reply]

Betacommand applied inappropriate username blocks

4.2) Betacommand applied inappropriate username blocks, without requesting community input into them

Comment by Arbitrators:

Is there a built-in expectation that an administrator seek community input before issuing a username block? Mackensen (talk) 11:06, 2 April 2007 (UTC)[reply]

Let me ask a further question: does WP:U accurately describe present practices? Mackensen (talk) 17:02, 2 April 2007 (UTC)[reply]

Would people agree that the question of a bad-faith username is unclear and that administrators necessarily have some latitude in this question? Mackensen (talk) 19:07, 2 April 2007 (UTC)[reply]

I have proposed 4.5.1 through 4.5.4 below, as reformulated and reorganized alternatives to this and other "4" findings of fact. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment - (I think I qualify as a party, this is my first rfarb) - There is a different between blatant username blocks, and unobvious ones. I have no issue with the many obvious blocks. The fact is, there were many good faith names, non obvious poliucy violations that were blocked, in my opinion, automatically. -- Chrislk02 (Chris Kreider) 19:16, 2 April 2007 (UTC)[reply]

Comment by others:

Proposed. Ryanpostlethwaite contribs/talk 21:51, 31 March 2007 (UTC)[reply]

Comment WP:U states that Blatantly inappropriate and bad-faith usernames can be blocked by an administrator. The usernames which were blocked by Betacommand were not blatantly offensive or bad faith. Other methods such as talking to the user regarding the name or bringing a discussion up at WP:RFCN should have been tried before blocking, especially when the evidence does seam to show that there was nothing wrong with the usernames which were blocked Ryanpostlethwaite contribs/talk 11:12, 2 April 2007 (UTC)[reply]

That's actually a very good question Mackensen, and to be perfectly honest, WP:U isn't all that clear on how administrators should deal with inappropriate usernames, appart from blocking on sight blatant infringements, what it does say is that if a username might go against policy, the best startinig place for discussion is with the user themselves, if this fails, then a posting at RFCN to gain a consensus on the matter. However, I don't agree that this gives an administrator the right to block usernames if they don't go against policy, this is why the proposal states without requesting community input into them. Only definate policy failures should be blocked on sight, this is where I think Betacommand failed with respect to username blocks Ryanpostlethwaite contribs/talk 18:54, 2 April 2007 (UTC)[reply]

Mmm there does need to be a clarification with this policy, particularly where the name is not so obvious, should it go to a noticeboard? Should we just assume good faith in our admins actions? I'm a bit weary myself with any additional instruction creep. Yet there might be some more guidance given as to when we should just leave it up to the admin. Part of our problem is that usernameblocks can be a subjective judgement at times. Also just a note it looks like this issue was resolved outside of arbcom (at least that is how I see it, as betacommand appears to have stated that he will shy away from username blocks). Regards —— Eagle101 ^{Need help?} 20:44, 2 April 2007 (UTC)[reply]

I've refactored this to place it with my other proposals. I think the relevant issue here is that a number of his blocks were overturned, at which point he started making actions that some argued were disrupting wikipedia to make a point. Thatcher131 00:57, 3 April 2007 (UTC)[reply]

Admins do have a fair bit of leeway in determining what is/isn't inappropriate and deciding if to block instantly or not. I can't say I'm a big fan of what WP:RFCN has become. Firstly it seems to be different to all other RFC processes in that it has a consequence at the end if found "against", not even permitting editors time to request a name change. Secondly the process of review of an admins action (which I'm sure has been added at some time), again seems to be very much against out normal practise of dealing with such issues. I guess to me it seems far too process oriented than result oriented. --pgk 14:45, 3 April 2007 (UTC)[reply]

In reply to Mackensen, yes I think the issue is unclear, and some latitude should be given. In addition it might do well for us to consider if WP:AGF applies to admin actions. —— Eagle101 ^{Need help?} 17:30, 3 April 2007 (UTC)[reply]

Betacommand ceased blocking users solely based on username in response to an RFC

4.3) Betacommand ceased blocking users solely based on username in response to an RFC.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. --pgk 21:10, 3 April 2007 (UTC)[reply]

Summary confusion

4.4) Several of the blocks made by Betacommand were appropriate but used an incorrect summary. For instance, he blocked User:Fatterwhales with a summary referring to the username policy, while the actual reason for the block was that it was a new account of vandal Fatwhales. The community was unaware of the latter, so overturned the block because there was no violation of username policy.

4.4.1) Betacommand has caused confusion by failing to provide a clear summary in the blocking summary field when performing blocks. For instance the block of User:Fatterwhales was misinterpreted by the community as an incorrect username block, when it was a pre-emptive block of ongoing vandalism using a series of disposable usernames.

Comment by Arbitrators:

This is an important point, although Betacommand is hardly the only administrator guilty of this. We can't be mind-readers. Mackensen (talk) 19:12, 2 April 2007 (UTC)[reply]

I agree. (Note: I have moved this proposal to here as as a subsection under "Betacommand's username blocks", and have renumbered appropriately.) Paul August ☎ 22:01, 12 April 2007 (UTC)[reply]

I have proposed 4.5.1 through 4.5.4 below, as reformulated and reorganized alternatives to these and other "4" findings of fact. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Support in principle, if Betacommand can show evidence that confusion over multiple (not just one or two) username blocks was merely down to an edit summary Ryanpostlethwaite contribs/talk 14:55, 30 March 2007 (UTC)[reply]

Comment by others:

Proposed. Based on evidence by Betacommand. Radiant! 11:55, 30 March 2007 (UTC)[reply]

Could be worded better. I've proposed 4.4.1 as an attempt at clarity. --Tony Sidaway 15:32, 30 March 2007 (UTC)[reply]

4.4.1 works for me Ryanpostlethwaite contribs/talk 15:33, 30 March 2007 (UTC)[reply]

Looking back at the InShaneeee case, I think we learned a lot about how problems with established, trusted editors tend to start with poor communication and persist when the parties fail to set up a good, civil line of communication. This failure to label his blocks correctly is a sign of that, and I note that others have complained that Betacommand failed to respond in a timely manner to queries about some of his blocks on his user talk page. --Tony Sidaway 16:11, 30 March 2007 (UTC)[reply]

Incorrect summaries are confusing, and this makes sense, as part of the problem in this case could have been avoided had Betacommand used correct summaries. Summaries that tell someone looking at the edit/admin action that say "I did the edit/action because of X" when really the edit/action was done because of Y mislead viewers as to the true reasoning. —— Eagle101 ^{Need help?} 20:49, 2 April 2007 (UTC)[reply]

I think this is a difficult issue. Sometime there are more than one reason to block and indeed one of the options for blocking usernames is that they resemble a known vandal. This is as I mention above part of the issue with things like WP:RFCN being overly concerned with the bureaucratic aspects rather than the outcome. One of the problems also encountered when making blocks such as the example is the general concept of biting newbies. To my mind (at least) a generic username block is a better message to a new user if the block ultimately is invalid (i.e. it wasn't really the intended target) than a straight accusation of being a specific vandal. --pgk 14:50, 3 April 2007 (UTC)[reply]

How about a sufficiently generic-reading compromise: something along the lines of "You have been blocked because your username may be in violation of the username policy. You are welcome to choose a different username and contribute. Reason: Resemblance to usernames used by vandal Willy on Wheels." --Random832 20:53, 3 April 2007 (UTC)[reply]

This is yet another example of poor communications in the form of a wrong edit summary. I think version 4.4 explains it better than 4.4.1, so I prefer 4.4. An error like this is not terribly egregious if taken all by itself, and I don't know that it warrants its own arb finding. However, it's valid as evidence of a pattern of carelessness about communication. 64.160.39.153 04:35, 11 April 2007 (UTC)[reply]

Inappropriate username blocks

4.5.1) Betacommand has blocked large numbers of editors for alleged violations of Wikipedia:username policy. For example, in February 2007, from 15:52, 1 February through 23:05, 27 February (UTC), Betacommand blocked approximately 1,000 editors ([6]). These blocks have attracted numerous complaints on multiple occasions ([7], [8], [9], [10], [11]). A number of Betacommand's username blocks have been overturned ([12]).

Comment by Arbitrators:

Proposed 4.5.1 through 4.5.4 as reformulated and reorganized alternatives to 4, 4.1, 4.2, 4.4 and 4.4.1. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Expanded and tweaked. Paul August ☎ 19:47, 17 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

4.5.1 through 4.5.5 seems to summarize the user name block issue quite well. Thatcher131 11:51, 16 April 2007 (UTC)[reply]

Incorrect block summaries

4.5.2) Some of the username blocks by Betacommand were appropriate but used an incorrect block summary. For instance, he blocked User:Fatterwhales with a summary referring to the username policy ([13]), while the actual reason for the block was that it was a new account of vandal Fatwhales. The community was unaware of the latter, so overturned the block because there was no violation of username policy.

Comment by Arbitrators:

Proposed 4.5.1 through 4.5.4 as reformulated and reorganized alternatives to 4, 4.1, 4.2, 4.4 and 4.4.1. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Use of an automated tool to disrupt Wikipedia:Requests for comment/User names

4.5.3) After complaints about his username blocks on 18 February 2007 and following, Betacommand began using an automated tool that made numerous reports at Wikipedia:Requests for comment/User names ([14], [15]), including several obvious violations ([16], [17], [18], [19]), giving as reason on his talk page, "Im getting tired of being bitched at for no reason. thus I am reporting VERY [sic] block to make sure the bitching stops ..." ([20]). Betacommand was blocked by Pschemp with a block summary: "refuses to stop bot reporting with this account" ([21]) and was unblocked 12 minutes later by Wangi ([22]).

Comment by Arbitrators:

Proposed 4.5.1 through 4.5.4 as reformulated and reorganized alternatives to 4, 4.1, 4.2, 4.4 and 4.4.1. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

For the sake of readability by all members of the Wikipedia community, would a clerk please oblige me by expanding terms such as WP:RFCN (the meaning of which is not immediately obvious to me as a longtime Wikipedian) to the pages they represent? Usually those pages have sensible names that summarize their content in English. Where this is not the case, it would be nice to have an English summary following the link in parentheses (for instance, "Request for comment on usernames", although Wikipedia:Requests for comment/User names is fine in this instance). --Tony Sidaway 21:48, 14 April 2007 (UTC)[reply]

Disruption of WP:AIV

4.5.4) After concerns were raised about his automated reporting at Wikipedia:Requests for comment/User names ([23]), on 28 February 2007 and continuing through 2 March, Betacommand began to report large numbers of obvious username violations at WP:AIV ( [24], [25], [26], [27]).

Comment by Arbitrators:

Proposed 4.5.1 through 4.5.4 as reformulated and reorganized alternatives to 4, 4.1, 4.2, 4.4 and 4.4.1. Paul August ☎ 21:23, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Unsatisfactory communication regarding username blocks

4.5.5) A number of editors expressed concerns regarding Betacommand's username blocks at User talk:Betacommand, including Benedict the Moor ([28], [29], [30]), (jarbarf) ([31]), Ryan Postlethwaite: ([32]) and Friday ([33]). Betacommand made no apparent direct response to any of the above editors, either at User talk:Betacommand, or at any of the four editor's talk pages. ([34]). One of the few direct responses Betacommand made to queries on his talk page, was a short and incomplete reply to a query by HighInBC: [35], [36]. There were four general discussions which included discussion of Betacommand's username blocks: Wikipedia:Requests for comment/Betacommand, and three discussions at WP:ANI; Betacommand did not participate in the RFC, and participated only minimally in the ANI discussions ([37], [38], [39]).

Comment by Arbitrators:

Proposed to complement 4.5.1 through 4.5.4. Paul August ☎ 19:59, 17 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

The username blocks were conducted inappropriately

4.5.6) Betacommand's username blocks were conducted inappropriately for the following reasons:

apparent blind application of inappropriate "rules", e.g., blocks for all usernames containing "jesus"([40]), "god" ([41]), "is back" ([42]), more than 32 characters ([43]), etc.;
no prior dicussion on the editor's talk page;
use of the "account creation disabled" blocking feature inappropriately making it impossible for the blocked editor to create an account with another username;
use of the generic block summary: "Please read our our username policy and choose another name {{usernameblocked}})", when an explanation of how the particluar username failed to satisfy policy would have been more helpful to the blocked editor in attempting to choose another username, as well as facilitating oversight by other editors and
failure to leave a block message on the blocked editor's talk page.

Comment by Arbitrators:

Proposed to complement 4.5.1 through 4.5.5. Paul August ☎ 22:44, 17 April 2007 (UTC)[reply]

Add new reason "no prior discussion ...", and reorder. Paul August ☎ 15:02, 18 April 2007 (UTC)[reply]

Changed "problematic" to "conducted inappropriately" to match other findings. Paul August ☎ 18:58, 19 April 2007 (UTC)[reply]

Comment by parties:

See my comment above. Betacommand ^{(talk • contribs • Bot)} 18:13, 18 April 2007 (UTC)[reply]

Comment by others:

Looks like the username blocks were done by a bot or script with some preprogrammed rules and responses (the later reporting to RFC/Username is apparently acknlowedged to be automated). Is there any evidence or comment on how the blocks were made? If the blocks were made by an automated tool, should there be a finding on this or should it be added to an existing finding (that is, related to the use of admin bots without authorization and/or the use of bots that have not fully been debugged). Thatcher131 15:00, 18 April 2007 (UTC)[reply]

Removal of external links

5) On 21 March 2007 and again on 23 March, Betacommand engaged in the high speed removal of thousands of external links identified as spam. 21 March AN/I discussion, 23 March AN/I discussion, evidence page. Betacommand relied on this survey identifying "doorway domains" for spam.

Comment by Arbitrators:

I have proposed 5.4, 5.5 below as reformulated and reorganized alternatives to 5 and 5.1. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

Betacommand's link removal raised concerns

5.1) The rapid removal of external links raised concerns that Betacommand was using an unauthorized bot on his main account, and also that he was removing links so rapidly that he did not have time to check to see if any were valid and not spam. Some removed links were contested here. For example, Betacommand classified links to USAID's web site as spam including the link to the official biography of the head of the agency [44]. Removal of USAID link about Foreign aid to Iraq from the Foreign aid to Iraq article.

Comment by Arbitrators:

I have proposed 5.4, 5.5 below as reformulated and reorganized alternatives to 5 and 5.1. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Comment by parties:

When betacommand was confronted by this, he explained he was using a source that classifed a specific domain as 85% spam. It appeared as though he felt that 85% spam meant automatically every link to that site could be removed. This was apparently a controversial point of view. -- Chrislk02 (Chris Kreider) 14:08, 3 April 2007 (UTC)[reply]

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

I think this is quite clear, otherwise there would not have been 2 ANI discussions about it. —— Eagle101 ^{Need help?} 14:03, 3 April 2007 (UTC)[reply]

Support, more or less. A lot of the removals were bad edits and some of them broke the affected articles (messed up template syntax etc). Also, Betacommand pretty much usurped the duties of the m:spam blacklist maintaners with the mass removals. The removals showed bad editing judgement, whether there was a bot or not. I think Betacommand's obstinacy and unresponsiveness when other editors pointed out the problem is a much bigger issue than the involvement of bots. I'll propose that any mass removal of this type (even done by consensus, and even if done manually) should not pretend to made with the full authority of a human editor exercising careful edit-by-edit judgement. The edit summaries should always invite the article's editors to revert the removal if they feel the removal was inappropriate. If the bot operator disagrees about a reversion any further action about it should be on a completely manual basis with normal human-to-human talk-page discussion about the specific edit, etc. Gotta go. 64.160.39.153 15:28, 10 April 2007 (UTC)[reply]

Unsatisfactory response

5.2) Betacommand's responses to the concerns raised by his link removal were generally unsatisfactory. See User_talk:Betacommand/20070301#Spam_removal and further. Also this conversation (the whole discussion is here):

Like I said before im currently developing that tool and trying to debug it -- Betacommand

I gather you don't intend to promise never to do this again? --AnonEMouse

The live debugging (on real articles) of the tool is strictly prohibited at this point, and it better not be used again without explicit permission. Debugging or not, it does not have community support and must be suspended. --Ram-Man

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

This is confusing. Could you please indicate the other parties to the conversation besides AnonEMouse? --Tony Sidaway 01:56, 3 April 2007 (UTC)[reply]

Sorry. The whole discussion is here, by the way. Thatcher131 02:00, 3 April 2007 (UTC)[reply]

Please don't butcher a conversation by picking quotes out of context and without double checking your facts please. see this for my response to AnonEmouse. Betacommand ^{(talk • contribs • Bot)} 02:08, 3 April 2007 (UTC)[reply]

On one hand you agreed to seek consensus for link removals, on the other hand this was the second critical discussion in 3 days on the same subject. Thatcher131 02:15, 3 April 2007 (UTC)[reply]

That is not a good reason to completely skewer the conversation. I did respond and my responce I feel was sufficient. yet when you outlined this conversation you left that out giving the assumption that I made no response to the issues raised. Betacommand ^{(talk • contribs • Bot)} 02:23, 3 April 2007 (UTC)[reply]

Added a link to the entire discussion right at the top. Thatcher131 02:30, 3 April 2007 (UTC)[reply]

Unsatisfactory response

5.2.1) There was a general consensus on Betacommand's talk page and the admins' noticeboard that Betacommand's responses to the link removal situation were unsatisfactory.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Alternate. Lays the onus on the various contibutors to the noticeboard and talk page rather than on me (I am reporting the views of others rather than stating it as fact). Ultimately it will be up to the arbitrators. I'm trying to lay out the events of the case in a logical order so that the arbitrators can pursue the links and decide what to do about it. Thatcher131 02:30, 3 April 2007 (UTC)[reply]

The link removal was conducted inappropriately

5.3) Betacommand has stated that the link removals were made by scripts, not by a bot [45]. If the removal of the external links was done by fully automated bot, this was a violation of the Bot policy. If the removal was done by a script that required manual confirmation of each edit, Betacommand exercised poor judgement in removing links indiscriminately without checking to see whether some of the links were appropriate in context, not to mention the edits were done at a high rate; an example of 500 removals within 20 minutes.

Comment by Arbitrators:

I have proposed 5.6 below as an alternatives to this. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Comment by parties:

I dont think the community is against external link removal. I think the communtiy is against external link removal by a faulty automatic tool, that broke some templates, removed valid sources, and then retionalized it by saying the site was 85% spam, all links to it should be removed. -- Chrislk02 (Chris Kreider) 17:40, 3 April 2007 (UTC)[reply]

Comment by others:

Proposed. Thatcher131 00:55, 3 April 2007 (UTC)[reply]

It could also be due to the fact that betacommand thought community agreement was with him when he removed links that were considered by an outside source to be 85% spam. (I only know about this because of what Chris said here). As this case shows, he did not enjoy the communities approval. Had Betacommand discussed his removals ahead of time, he could have saved some grief, and may have been advised of a better course of action to take. (perhaps taking more time to further investigate rather then taking one source at its word). In any case being that it supposedly was 85% spam, Betacommand would have done well to review and make sure he was not removing the 15% good links. —— Eagle101 ^{Need help?} 17:37, 3 April 2007 (UTC)[reply]

Chrislk02, we don't know if the tool was automatic or not, it could very well have been a semi-automatic tool. Betacommand's reason for using a tool to remove links was likely due to that source showing that some links were 85% spam. In addition he did lack judgement in running a new tool, and not checking to see if it was properly debugged. One of the first things that bot operators and coders do (I have done both) is check to make sure that the settings and or code is configured properly, and is not causing unintended damage. —— Eagle101 ^{Need help?} 17:53, 3 April 2007 (UTC)[reply]

I will agree that we cannot prove it was run automatically. However, links to valid sources were deleted on multiple occasions. After the first instance, in betacommands defense, he reverted a handful of his changes. He however began the same behavior the next day. I believe that a.) the removal of several, at least arguably appropriate sources, along with many other high speed link removals coupled with the errors in templates and other formatting contexts that were caused by the link removal lead me to believe, even though it may have been running in a semi automatic way, betacommands involvement was that of an automatic tool. In other words, i can click "yes i want to delete this" 60 times a minute without viewing any of the actual links, following them to see what they contain, or viewing the edit afterwards to make sure nothing messed up. I think in this situation, automatic, or semi automatic is kind of a mut point to argue. -- Chrislk02 (Chris Kreider) 21:29, 6 April 2007 (UTC)[reply]

I have presented my evidence suggesting that he couldn't have been manually inspecting the bot edits during his last link removal incident, at Wikipedia:Requests for arbitration/Betacommand/Evidence#Evidence of operating a fully automated bot. (sorry if this is not the correct place to report this) -- intgr 09:49, 11 April 2007 (UTC)[reply]

Chrislk02, I think the community favors removal of bad links and opposes removal of good links. The issue is that Betacommand didn't make any link-by-link effort to distinguish good from bad. Wikipedia has a m:spam blacklist to implement mass exclusion of links from given sites, but its use is considered drastic and is reserved for extreme cases. Betacommand basically programmed a bot to create an alternate implementation of the blacklist, bypassing the careful judgement of the meta admins as to what sites would be on it. 64.160.39.153 07:15, 13 April 2007 (UTC)[reply]

Reworded, mentioned part of the 500 removals over 20 minutes (25 edits per min) - Penwhale | ^{Blast him / Follow his steps} 13:36, 15 April 2007 (UTC)[reply]

The link removal was conducted inappropriately

5.3.1) Betacommand has stated that the link removals were made by scripts, not by a bot [46]. Even so, Betacommand's removal of external links was inappropriate and showed poor judgement for 3 reasons; 1) he used an automated tool to edit with bot-like speed from an account that did not have a bot flag; 2) his automated tool was still under development [47] and made mistakes, including breaking templates; and 3) links were removed indiscriminately without checking to see whether some of the links were appropriate in context.

Comment by Arbitrators:

I have proposed 5.6 below as an alternatives to this. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Alternate version, trying to say exactly why what he did was wrong. As far as I know, automated tools under development should be put to limited use until they are debugged, not used for removing 3000 links on one day. And it seems like, per bot policy, a bot flagged account should have been requested to make such rapid edits, even if the tool was a script and not a bot. Thatcher131 18:02, 3 April 2007 (UTC)[reply]

I think the two versions should be combined. Both say good and important things. I like this second one better if I have to pick one.64.160.39.153 07:24, 13 April 2007 (UTC)[reply]

High-speed removal of external links

5.4) Beginning on 20 March 2007, Betacommand engaged in high-speed removal of external links. From 22:38, 20 March, through 4:35, 21 March (UTC), he removed 418 external links ([48]); from 14:16, 21 March through 17:34 (UTC), he further removed 2,121 external links ([49], [50], [51], [52], [53]). Beginning at 13:16, 21 March, the link removals were criticized at User talk: Betacommand (See "David Wong" through "Yes, please stop" and following) and WP:ANI ([54]).

On 23 March, from 13:15 through 15:29 (UTC), Betacomand removed a 104 external links ([55]) which was again criticized at ANI ([56]), as well as Betacommand's reliance on this survey identifying "doorway domains" for spam. The rapid removal of external links raised concerns that Betacommand was using an unauthorized automated tool on his main account, and also that he was removing links so rapidly that he did not have, or take, time enough to determine if the links were valid.

Comment by Arbitrators:

Proposed 5.4 and 5.5 as alternatives and reformulations of 5 and 5.1. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Some minor fixes Paul August ☎ 21:58, 15 April 2007 (UTC)[reply]

Fix my fix. Paul August ☎ 05:06, 16 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Inappropriate link removals

5.5) Many links were removed inappropriately. For example, Betacommand classified as "spam" all links to United States Agency for International Development's web site www.usaid.gov, resulting in the removal of: the link to the Global Development Alliance homepage from the article "The Global Development Alliance" ([57]), the link to the USAID Office of Foreign Disaster Assistance homepage from the article "Office of Foreign Disaster Assistance" ([58]), the link to the USAID's page on Hurricane Stan flood relief and recovery efforts" from the article "Hurricane Stan" ([59]), the link to the Biography of Andrew S. Natsios from the article of the head of the USAID, "Andrew Natsios" ([60]), the link to the USAID's Iraq page from the article "Foreign aid to Iraq" ([61]) and others.

Comment by Arbitrators:

Proposed 5.4 and 5.5 as alternatives and reformulations of 5 and 5.1. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

The link removal was conducted inappropriately

5.6) Betacommand's removal of external links was inappropriate and showed poor judgment for the following reasons:

he used an automated tool to edit with bot-like speed from an account that did not have a bot flag;
his automated tool was still under development ([62]) and made large numbers of mistakes ([63], [64]), including breaking templates ([65], [66]) breaking list formatting ([67], [68]), leaving empty sections ([69], [70]), and deleting categories and inter language links ([71], [72]);
he used an inappropriate methodology of identifying as spam, all links to web sites listed as having a "spam percentage" above a certain percent, according to a "study" by WebmasterWorld as reported here ([73], [74]); and
links were removed indiscriminately without checking to see whether some of the links were appropriate in context.

Comment by Arbitrators:

Proposed as an alternative to 5.3 and 5.3.1. Paul August ☎ 22:17, 14 April 2007 (UTC)[reply]

This gets to the heart of the problem. Mackensen (talk) 11:40, 16 April 2007 (UTC)[reply]

Add "and leaving empty section headings" to number 2. Paul August ☎ 04:18, 18 April 2007 (UTC)[reply]

Expanded "reason" two and added links. Paul August ☎ 17:17, 18 April 2007 (UTC)[reply]

Add two more links, change "made mistakes" to "made many mistakes". Paul August ☎ 17:46, 18 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

5.4 through 5.6 is a good summary of the link removal problem. Whether #1 is sanctionable depends on bot policy, which is somewhat vague on the issue of scripts (although it does say, when in doubt, ask). Issues 2, 3 and 4 go to editorial judgement but not necessarily administrative judgement. Thatcher131 11:55, 16 April 2007 (UTC)[reply]

Unsatisfactory communication regarding link removals

5.7) A number of editors expressed concerns regarding Betacommand's link removals at User talk:Betacommand, including DMighton, wrp103 and Kla'quot ([75]]); intgr and Ehheh ([76]); Rsholmes, Susanlesch and Jordan Brown ([77]); AnonEMouse ([78]); Conti ([79]); intgr (again) and Arichnad ([80]); AnonEMouse (again) ([81]); Mithridates, BigDT, Arichnad (again), HighInBC and taviso ([82]); Angr, Flex, and Violask81976 ([83]); 64.160.39.153 and Fredsmith2 ([84]); LeinadSpoon ([85]); Vanrozenheim ([86]); Fredsmith2 (again) and Onorem ([87]); Ehheh and AnonEMouse (again) ([88]); Gandoman, Chacor, kingboyk and Dbachmann ([89]); George.Saliba ([90]). Betacommand was generally unresponsive to the above editors, ignoring many, giving curt replies to others and generally failing to adequately address the editorial concerns being raised.

Comment by Arbitrators:

Proposed to compliment to 5.4 through 5.6 Paul August ☎ 04:49, 18 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Though not specifically related to this link-removal incident, Betacommand showed similar curt and incivil responses in an earlier link-removal incident. This information is also on the evidence page. Evidence of incivility can be found at these difs: [91] and [92] and [93] and [94]--Jayron32|talk|contribs 04:53, 28 April 2007 (UTC)[reply]

Pallywood

6) Betacommand blocked Jaakobou (talk · contribs · deleted contribs · logs · filter log · block user · block log) for edit warring at the article Pallywood (edit | talk | history | protect | delete | links | watch | logs | views). After critical discussion on the Noticeboard, Betacommand unblocked Jaakobou about an hour later. Betacommand has acknowledged that he made a mistake, and had tried to "stop the edit war without enough information".

Comment by Arbitrators:

This is small beer. Mackensen (talk) 14:20, 3 April 2007 (UTC)[reply]

Smallish beer perhaps (I don't suppose Jaakobou would agree), but also perhaps part of a pattern of poor administrative judgment. Paul August ☎ 15:48, 13 April 2007 (UTC)[reply]

I've proposed an alternative 6.1 "Other controversial blocks" below. Paul August ☎ 22:00, 13 April 2007 (UTC)[reply]

Comment by parties:

I would like to point out, that this issue, if it were an isolated incident, would probably be forgivable (while definitly not appropriate, we all make mistakes). What I think is important to take into account in the purported history of poor administrative decisions. And, when this innapropriate block gets added onto the rest of it, I think it starts to call into question betacommands adiminstrative decision making capabilities. -- Chrislk02 (Chris Kreider) 14:21, 3 April 2007 (UTC)[reply]

Comment by others:

Proposed. No one has mentioned it in the arbitration case yet except Betacommand (to acknowledge the mistake), but several people (who have not commented here yet) raised it on the noticeboard as one reason that Betacommand should no longer be trusted as an admin. Personally, I don't think it is a big deal and there is certainly no pattern of blocking during content disputes, as there may be in other arbitration cases. Thatcher131 01:46, 3 April 2007 (UTC)[reply]

This kind of thing happens quite a lot. The edit warring itself was the problem, so it's not really on to go after the one person who seemed to be genuinely interested in stopping the warring. We should always cut genuinely disinterested parties a lot of slack when they perform administrative functions intended to stop a brawl. --Tony Sidaway 01:54, 3 April 2007 (UTC)[reply]

I agree with this one, it was an inappropriate block, Jaakobou had reverted 3 times in 3 days, and Betacommand had contrubuted to Pallywood, hence a conflict of interest with the block. This was the final straw before arbitration, so should be included. In my mind, it shows poor administrator judgement in a number of areas, which is what this case comes down to. Not merely a very serious problem with say blocking, but more continued poor judgement on a number of less serious issues Ryanpostlethwaite contribs/talk 10:45, 3 April 2007 (UTC)[reply]

I'm going to point out that it looks like he was uninvolved until the day that he made an edit and subsequently blocked an editor. This looks more like a screwup on beta's part then any actual malice on his part. As far as I know betacommand does not normally edit articles in this area, and most likely just came across it, and attempted to calm down the impeding editwar. If there were a pattern of blocking during content disputes I would be worried, but here I don't see such a pattern. —— Eagle101 ^{Need help?} 14:00, 3 April 2007 (UTC)[reply]

Yeah sorry, I agree there, he did only edit it on the day of the dispute, but what I was trying to get at is that he seamed to have blocked to get it the way he wanted Ryanpostlethwaite contribs/talk 14:16, 3 April 2007 (UTC)[reply]

It appears to me that he didn't know why there was edit warring. That it was over something so ridiculous as whether to put a template on the article is not immediately obvious. --Tony Sidaway 22:15, 3 April 2007 (UTC)[reply]

I was under the impression he was responding to an earlier request for assistance an/i --pgk 22:27, 3 April 2007 (UTC)[reply]

Other controversial inappropriate blocks

6.1) Betacommand has performed other ~~controversial~~ inappropriate blocks. These include:

21 October: Betacommand's first block came 34 minutes after being made an administrator. After noticing that 69.85.184.134 (talk · contribs · deleted contribs · logs · filter log · block user · block log) was adding the template " toomuchtrivia" to various pages, Betacommand, with no prior warning, blocked the editor for vandalism and reverted all the editors edits ([95]). These actions drew the immediate complaints of two administrators ([96]), saying that the template additions were valid, and the editor should not have been blocked. The editor, subsequently unblocked by Betacommand, has not edited since.
21 December: Without warning or prior discussion, Betacommand blocked long-time established editor Irpen (talk · contribs) for 48 hours for "personal attacks" ([97]). Betacommand made no comment about the block, on Wikipedia, until nearly a day later ([98]), saying that the block was because of Irpen's comments at WP:PAIN ([99]). This block was criticized at WP:ANI ([100]) and at User talk:Betacommand ([101]), and Alex Bakharev unblocked ([102]).
26 February: Betacommand blocked Hillock65 (talk · contribs) and Chuprynka (talk · contribs), with an expiry time of indefinite ([103], [104]). These blocks were criticized at WP:ANI: [105]) and Alex Bakharev unblocked these editors ([106], [107]).
26 March: Betacommand reverted the removal of a notability tag at Pallywood, ([108]), and warned at Talk:Pallywood that "If a user removes the Noteability [sic] tag before this discusion [sic] above is concluded I will block them for edit waring." ( [109]). Later that day Jaakobou (talk · contribs) removed the notability tag, Betacommand reverted ([110]), and blocked Jaakobou (talk · contribs) for 24 hours ([111]). After criticism of the block at WP:ANI, by administrators Jayjg, Friday, SlimVirgin, jossi, Chrislk02, Mel Etitis and others ([112]), Betacommand unblocked Jaakobou.

Comment by Arbitrators:

Proposed as an alternative to 6 above. Paul August ☎ 22:00, 13 April 2007 (UTC)[reply]

I'm uncomfortable with this idea of a "controversial block." At this stage any block on any editor of standing is by definition controversial. Unless we're prepared to rule on whether Betacommand should have blocked Irpen, and whether Irpen was disrupting WP:PAIN, I don't see how this is helpful. Making a controversial block is not a bad thing; making an unreasonable block is. Mackensen (talk) 22:11, 13 April 2007 (UTC)[reply]

Geogre, I'm not interested in shielding anybody. A block can be controversial and still be a correct application of policy. Now, if these are all being overturned, then let us drop the weasel words and state "Betacommand's blocks are often overturned" or words to that effect. Mackensen (talk) 00:33, 14 April 2007 (UTC)[reply]

I've replace the word "controversial" with "inappropriate" per Mackensen. Paul August ☎ 03:28, 14 April 2007 (UTC)[reply]

I've moved "His first block ..." from finding 10 "History of poor judgment" below, to here and expanded. Paul August ☎ 18:04, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

If we took Mackensen's statement at face value, then we have to ask why he would wish to shield Betacommand this way. The point to "controversial" is "controversial to whom?" In the case of blocks, a block that provokes controversy among other administrators is one that is fairly clearly wrong. When a mass of other administrators step in to criticize a block this is establishment of consensus. AN/I is where blocks get reviewed, where issues get discussed, and what we see here is an extensive review and uniform dismissal and reversal of the blocks. When we see this continue to a second block of that nature, and then a third, we are seeing a pattern of a person whose actions are pretty demonstrably out of step with the community of administrators and using the block button in a way not commensurate with the community's standards. That is what a "controversial" block is and why it is evidentiary. Geogre 23:34, 13 April 2007 (UTC)[reply]

A block that "provokes controversy among other administrators" isn't the same as a "clearly wrong" block. A "clearly wrong" block is a block that should not have been performed under any circumstances. Administrators are not especially privileged in deciding what is and is not an appropriate block, Although they are usually more clued-in on policy and what makes Wikipedia tick, this doesn't make them omniscient. --Tony Sidaway 23:44, 13 April 2007 (UTC)[reply]

There is an important question of categorization lurking here. It would seem that all three of these incidents involved what are now widely considered to have been problematic blocks, though it hasn't been clear whether some are considered within the scope of the case or not. One could combine these with the questioned username blocks and readily infer "a pattern of questionable blocking." And yet, the three incidents above involved three very different types of problematic blocks. The first, an overeager "personal attacks" block of a respected editor, a block said by some to have been IRC-related: an unwarranted block in my view but Betacommand's only known block of this kind. The second, a pair of incorrect but presumably good-faith blocks based on a gross misinterpretation of an investigation of sockpuppetry allegations: plainly unwarranted blocks but Betacommand's only known blocks of this kind. The third, inappropriate blocking of an editor with whom Betacommand was arguably involved in a content dispute: an unwarranted block but Betacommand's only known block of this kind. So ... a pattern of bad judgment associated with the crucial admin function of blocking ... or a few discrete, forgiveable, isolated incidents involving a busy, dedicated sysop responsible for hundreds or thousands of administrator actions a month? Making that kind of call is exactly what we pay the arbitrators for. Newyorkbrad 03:48, 14 April 2007 (UTC)[reply]

Response to Mackensen: I did not mean to imply an improper desire to shield a particular user, but rather why one would wish to shear off the history of a person's actions when considering whether they were proper in a particular instance. In other words, when other users have been brought into the docket for non-administrative actions, all sorts of past statements have been entered as "evidence." In those cases, I believe the evidence is worth much less than a fig: one can find a person who will find any statement disruptive or incendiary or completely correct. On the other hand, with actions, we have a different thing altogether. A person whose actions have consistently brought about disapproving review from the other (more experienced) users is establishing, in my view, a very strong ledger of evidence. When the disapproval is WP:AN/I and WP:AN and the action is blocking users, I think the evidence is very, very strong. This is, in short, other administrators looking at administrative actions (the worst ones we do) and finding the actions improper. I'd rather exclude a comment here or there (the infamous "f-bomb" used by this or that blocked user) and include any history of overruled blocks, deletions, or protections. Geogre 04:17, 14 April 2007 (UTC)[reply]

Response to Tony Sidaway: Yes, I would say "automatically wrong." If each of us has the unique power to decide when to block, then we have nothing but solipsism and wheel wars if we don't yield always to the consensus and majority of the the group. We find the group and the group's guidance on the internal WP pages of the noticeboard and its children. This is, I would suggest, the best possible review venue, because people get to click on links, read carefully, and state calmly. It beats the heck and stuffing out of any more "rapid" and scattershot forum. Geogre 04:17, 14 April 2007 (UTC)[reply]

I can't agree that a block that is queried by other administrators is automatically wrong, or that we need "solipsism and wheel wars" to determine when a block is correct. However this is beside the point. Betacommand's failure to discuss subsequently is to me most problematic. Not before, but afterwards when the blocks were queried. This was also the chief cause of the problem in the recent InShaneee case. Making mistakes is something that will happen to any busy administrator. Dealing with them correctly when they happen is a very important part of being an administrator. --Tony Sidaway 08:25, 14 April 2007 (UTC)[reply]

Betacommand was blocked for historic actions

7 Discussion of an historic problem was added to a current discussion. Betacommand was mistakenly blocked to prevent further "bad" blocks, despite it not being a current issue and one which Betacomnand believed to have been resolved.

Comment by Arbitrators:

Unless the scope is expanded to include the blocking administrator this isn't relevant. Mackensen (talk) 19:13, 2 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Proposed --pgk 13:57, 30 March 2007 (UTC)[reply]

It should be noted that the blocking administrator acknowledged this was a mistake and it was immediately reversed. I don't believe it should count against any of the parties. Newyorkbrad 14:29, 30 March 2007 (UTC)[reply]

I concur. As the admin who unblocked him, this was a misunderstanding and should be discounted. -- RM 15:04, 30 March 2007 (UTC)[reply]

Not sure what it being a mistake has to do with it or not, this is a finding of fact and this factually occurred, this is not trying to draw a conclusion. That aside given that part of this case is Betacommand acting in good faith and a less than desirable outcome occurring, the fact that we believe we should ignore the good faith actions of another admin, even though the outcome was not ideal seems to be relevant. Not to mention that Betacommand had responded to previous criticism is this area, yet it seems to have haunted him also seems relevant. --pgk 15:45, 30 March 2007 (UTC)[reply]

This isn't really relevant to the case. Some people introduced old stuff to illustrate a historical problem. Others misread and blocked in haste. The error was fixed quickly and (as far as I know) amicably. Business as usual. --Tony Sidaway 15:58, 30 March 2007 (UTC)[reply]

Betacommand's record as an administrator

8) Betacommand has a good record of using his administrative tools in ways that usually benefit the project. Betacommand has generously volunteered his time to assist with bot approvals, fighting spam, and fighting vandalism.

Comment by Arbitrators:

Comment by parties:

I think this is the appropriate place for this. I agree that betacommand partipates in may beneficial areas of the project, However, the question is, should this offset disruptive behavior? An administrator. being blocked 3 different times by 3 different administrators (not including the most recent erronous block) has to be doing something innapropriate. -- Chrislk02 (Chris Kreider) 20:16, 2 April 2007 (UTC)[reply]

I see two blocks: one by Dragons Flight, and one by Pschemp. The latter was overturned almost immediately. The third, I'm guessing, is when Betacommand accidentally blocked himself, and I trust we aren't holding that against him. Mackensen (talk) 20:21, 2 April 2007 (UTC)[reply]

My sincere apolagies. There are two. I still stand by that is 2 more than an administrator should have. There are also threats of blocks that I remeber. If it had been a normal user, would they have been blocked an punished much more severly? The question is, how far, if at all, are administrators actions above that of non administrators? It is my opinion that administrators should be held to higher standards. -- Chrislk02 (Chris Kreider) 20:50, 2 April 2007 (UTC)[reply]

No one's disagreeing that admins should be held to higher standards, but our purpose here is to determine whether Betacommand should have been blocked (i.e. has he been acting improperly). I've been blocked by another administrator before–does that automatically make me less trustworthy (to take an example?) Mackensen (talk) 21:25, 2 April 2007 (UTC)[reply]

Bizarre and destructive actions that were only stopped under threat of blocking should also be considered (see the extlink deletion incident) even when there wasn't an actual block. Obstinacy of that sort is terrible judgement all by itself. 64.160.39.153 03:04, 10 April 2007 (UTC)[reply]

Comment by others:

Proposed. Somewhat of a copy of a statement from Daniel Brandt Wheel War, but I think it needed to be mentioned in some form. alphachimp 04:55, 31 March 2007 (UTC)[reply]

The proposal from which this is copied didn't make it out of the workshop. Betacommand is a very active and committed administrator, however. --Tony Sidaway 05:41, 31 March 2007 (UTC)[reply]

Support Ryanpostlethwaite contribs/talk 17:04, 31 March 2007 (UTC)[reply]

Someone might consider the formulation that I proposed in the Philwelch, Deltabeignet, and Konstable cases (and it was adopted as finding 1 in Philwelch). Newyorkbrad 19:52, 2 April 2007 (UTC)[reply]

Automated image deletion

9) On 27 November 2006, from 17:52 to 19:43 (UTC), Betacommand used an unauthorized automated tool to delete 1,590 images ([113], [114], [115], [116]). He apparently indiscriminately deleted every image which was tagged for speedy delete, with no regard for {{Replaceable fair use disputed}} tags or talk page disputes concerning whether fair use deletion criteria applied. These deletions were criticized at User talk:Betacommand (see "deletion" through "Block" and WP:ANI ([117]). On November 28, he was blocked for a week by Dragons flight with a block summary of "Using an unauthorized deletion bot" ([118]), and unblocked six and a half hours later by Geni (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) with a block summary of "I don't think he is going to do that again" ([119]).

Comment by Arbitrators:

Proposed. Paul August ☎ 14:36, 13 April 2007 (UTC)[reply]

Corrected and added some information. Paul August ☎ 05:03, 16 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Unsatisfactory communication regarding image deletions

9.1) A number of editors expressed concerns regarding Betacommand's image deletions on User talk:Betacommand, including Irpen ([120]), Tvccs (twice) ([121]), Visor ([122]), Citizensmith (twice) ([123]), 172.202.174.36 ([124]), Dgies (twice) ([125]), HighInBC (twice) ([126]), Jenolen ([127]), HarryCane ([128]), Wisekwai: ([129]), Zanimum ([130]), Timothyarnold85 ([131]), ceejayoz (twice) ([132]). Betacommand made no apparent direct response to any of the above editors either at User talk:Betacommand or at any of the editor's talk pages. ([133]). The only apparent direct responses Betacommand made to queries on his talk page, were to answer technical queries about how the deletions were accomplished ([134], [135]). Betacommand's only other apparent comments on the image deletions were two on WP:ANI ([136], [137]).

Comment by Arbitrators:

Proposed to complement 9. Paul August ☎ 18:09, 16 April 2007 (UTC)[reply]

Reformat, no substantive change. Paul August ☎ 02:29, 18 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

The image deletion was conducted inappropriately

9.2) Betacommand's image deletion was inappropriate and showed poor judgment for the following reasons:

he used an automated tool to edit with bot-like speed from an account that did not have a bot flag;
he used an inappropriate methodology of deleting all images tagged for speedy delete, with no regard for {{Replaceable fair use disputed}} tags or talk page disputes concerning whether fair use deletion criteria applied; and
he exercised no independent judgment as to the appropriateness of each image deletion.

Comment by Arbitrators:

Proposed to compliment 9 and 9.1. Paul August ☎ 18:41, 16 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

History of poor judgment

10) Several past incidents demostrate that Betacommand has a history of poor judgment:

His semi-automated (WP:AWB) removal of 130 current event tags ([138]) drew complaints ([139], [140], [141]).
His semi-automated (WP:AWB) template substitution on 104 user pages ([142]) drew complaints ([143], [144], [145]).
His removal of over 6,500 self-links at high-speed, ([146], [147], [148], [149], [150], [151], [152], [153], [154], [155], [156], [157], [158], [159], [160], [161], [162]), caused many instances of loss of desired bolding, for example in the first occurrence of a page title ([163], [164], [165], [166], [167]) and in taxoboxes ([168], [169]), and drew complaints ([170], [171]).
His unprotection of 171 editor's user pages ([172], [173] drew complaints ([174], [175], [176], [177], [178], [179], [180]).
His edits related to Template:Deletedpage ([181]) drew complaints ([182]).

Comment by Arbitrators:

Proposed (and fixed per Newyorkbrad's comment below - thanks). Paul August ☎ 04:50, 19 April 2007 (UTC)[reply]

Moved "His first block ..." to finding 6.1 "Other imappropriate blocks", above. Paul August ☎ 18:08, 19 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

I don't quite understand the first subparagraph. Who is "the editor" or what is the block referred to? There may be a couple of words missing. Newyorkbrad 04:40, 19 April 2007 (UTC)[reply]

WP:RFC/U was operating incorrectly and contributed greatly to the confusion

11) The way WP:RFC/U was operated by a small number of administrators together with the considerable flux within the username policy at the time created additional confusion. The conduct of several administrators was below the levels expected by the community with a number of problematic username blocks being overturned outwith the RFC/U process, despite these username blocks being submitted to that process. On several occasions, a RFCU case was opened by one user, who also commented on the block, closed the case and unblocked the user, all in a way which compromised their impartiality. This behaviour contributed to the considerable confusion surrounding Betacommand's username blocks, many of which may be regarded as inappropriate, but which fall within the range of administrators discretion.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed -- Nick^t 23:34, 24 April 2007 (UTC)[reply]

At that point the role of RFCN was unclear, however, username blocks which were inappropriately blocked were overturned rightly so. Betacommand did block usernames inappropriately, ones which were clearly not against policy. Ryan Postlethwaite 23:40, 24 April 2007 (UTC)[reply]

By the way, I think your referring to me when you talk about submitting and overturning blocks, so by all means provide the diffs in this proposal - I stand firm by what I did as the username blocks were just clear biting. Ryan Postlethwaite 23:42, 24 April 2007 (UTC)[reply]

Template

11) {text of proposed finding of fact}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed remedies

Note: All remedies that refer to a period of time, for example to a ban of X months or a revert parole of Y months, are to run concurrently unless otherwise stated.

Betacommand forbidden from username blocks

1) Betacommand is prohibited from making blocks related to username policy for X weeks/months/years/indefinitely.

Comment by Arbitrators:

Given the open question over whether the username policy describes present practice I would be hesistant to endorse this. Mackensen (talk) 19:14, 2 April 2007 (UTC)[reply]

Comment by parties:

I don't support this, someone is either trusted or not with the tools, and if they are, they should be able to perform all tasks Ryanpostlethwaite contribs/talk 15:08, 30 March 2007 (UTC)[reply]

Username blocks are a very small part of adminship, he can just concentrate his use of the tools elsewhere. It's not like it's a major problem, other sysops can handle it I'm sure. Milto LOL pia 16:10, 30 March 2007 (UTC)[reply]

I have basically stopped usernameblocks. Betacommand ^{(talk • contribs • Bot)} 17:36, 18 April 2007 (UTC)[reply]

Comment by others:

This would be independent of sysop status, i.e., even if not desysopped, or desysopped and later resysopped. Might make an alternative to desysopping, for this issue anyway. Milto LOL pia 08:50, 30 March 2007 (UTC)[reply]

Not supported by the evidence. He had voluntarily ceased username blocks some weeks prior to the application for arbitration. --Tony Sidaway 15:26, 30 March 2007 (UTC)[reply]

If he plans to reverse that decisions, it may become and issue and perhaps should be nipped in the bud. If he won't reverse his decision, then this remedy wouldn't do him any harm. Milto LOL pia 16:09, 30 March 2007 (UTC)[reply]

On the other hand, he could reverse his decision and comply with the Username policy forever after. This is a trusted member of the Wikipedia community. Clarification of the username policy should be enough. --Tony Sidaway 16:13, 30 March 2007 (UTC)[reply]

I doubt that, learning from mistakes seems not be be his forte, otherwise this wouldn't be in arbitration. I have no strong opinions about it though, it doesn't affect me and I'm just brainstorming. Milto LOL pia 16:15, 30 March 2007 (UTC)[reply]

Not a fan of this sort of result, per User:ryanpostlethwaite the tools are a package, either the community trusts you with them or they don't. I can't see it as too healthy anyway, what if he blocks for username but dresses it up as something else?, what if someone accuses him of that?... Also since this issue seems to have been resolved anyway, it seems a needless remedy. --pgk 18:58, 30 March 2007 (UTC)[reply]

Likewise, I am not a fan of this option. Frankly, I don't like the precedent, and I don't like the statement that it sends (either to the community or to Betacommand). I do not support saying "we trust you, except in these circumstances..." I think it sends the wrong statement about admin-ship. Admin-ship is a matter of whether the community trusts this member with a set of tools. We do, or we do not. Until we can (and decide to) separate the tools into subsets (and, more importantly, the functions that require the tools), I don't think I could endorse such an action. Philippe 20:37, 10 April 2007 (UTC)[reply]

Betacommand prohibited from admin bot tools

2) Betacommand is prohibited from using any automatic or semi-automatic tools to perform administrative actions (save rollback)

Comment by Arbitrators:

This raises a larger policy question. As I understand it, admin bot tools are officially not allowed but in practice useful instances are allowed anyway. I personally don't mind the contradiction but the community might want to clarify its stance. Mackensen (talk) 11:14, 2 April 2007 (UTC)[reply]

Comment by parties:

The only admin tools that were (simi)automatic was the firefox hack I used for Image deletion, and my monobook. yes I had a IRC bot that reported usernames to me, when the usernameblock issue came up I started to have it report usernames to an user subpage along with the IRC report. I have used many javascript tools that are freely available for others to see and use in my monobook. I cant code javascript so I have gathered these scripts from other users. Betacommand ^{(talk • contribs • Bot)} 17:45, 18 April 2007 (UTC)[reply]

Comment by others:

Not sure about this. On one hand, it doesn't seem to be an ongoing problem, on the other hand it seems to have cropped up as a problem in Betacommand's behavior on at least two separate occasions and in two different contexts (image deletions and username blocks). --Tony Sidaway 16:02, 30 March 2007 (UTC)[reply]

So, how much time is allowable between "ok, sorry I won't do it again" does a person have to put between repeated screwups of a very, very very clear policy to keep it from being actionable? It's not like the policy is well-worded to allow it to be ignored at one's discretion, like those irritating hindrances caled WP:NPA and WP:CIVIL. It's very straight-forward: don't use unauthorized bots. Just don't. This has happened several times now? Not to be analyzingt he arbitrators, but I doubt they would've accepted this if they thought "oh it's ok, he won't do it again." Milto LOL pia 16:19, 30 March 2007 (UTC)[reply]

As far as I'm aware there is no evidence that Betacommand used unauthorized bots more than once. If he did, we should have a finding to that effect. --Tony Sidaway 16:49, 30 March 2007 (UTC)[reply]

Not sure, since it would imply that use of automatic tools for admin tasks is acceptable elsewhere, not sure the community as a whole supports that notion. --pgk 19:01, 30 March 2007 (UTC)[reply]

Mackensen, I don't think the workshop yet conveys what was actually going on in this case. I'm going to try and look at it tonight. There has been a great deal of community resistance to the idea of admin bots, but many admins seems to use scripted tools with little outcry. I'm not sure yet whether the complaints here are that BC used a bot on his admin account or that he used scripts to enable rapid editing and then used poor judgement in making his edits. The workshop is deficient on this so far. Thatcher131 17:08, 2 April 2007 (UTC)[reply]

Bot policy is unclear on admin bots. There are several admins besides Betacommand who seem to use automated tools to make high speed blocks and/or deletions. This is an area where the Bot approvals group has left the community without adequate guidance. How many deletes per minute may a script-assisted admin make without a bot flag? How can admin-assist scripts be debugged if admin-scripts are kept under the table? Exactly how much automation is permitted and how much human intervention is required for an admin bot or script? Thatcher131 05:20, 15 April 2007 (UTC)[reply]

I think that is a broader issue than this case and one for the community, the previous discussions on such matters boil down to BAG not believing they have a community remit to approve admin bots for operation. Indeed some non-admin bots cause problems, not with the basic issues the BAG considers but merely because the base idea of the bot ends up lacking support for it's operation. --pgk 08:48, 15 April 2007 (UTC)[reply]

As a member of BAG, I don't believe we have a community remit to approve admin bots for operation. Any clarification with regards to that point would be welcome. With regards to your second point, I (and I believe, we) certainly attempt to determine whether a task is likely to be controversial before approving it although, of course, as a team mostly concerned with technical issues there's a limit to how far we can take this. Unfortunately, a negative consequence of our diligence is that we can then be accused of bureacracy, bias, and so on (see Wikipedia:Bots/Requests for approval/Rschen7754bot 3 and Wikipedia:Village_pump_(policy)#BAG_being_un-wiki.3F for a particularly vocal case, albeit one which is now resolved).

With specific regards to BetacommandBot, we didn't actually approve him to remove "spam" links, only to list them. Nonetheless we hastily removed approval for that task (and ultimately all of his bot approvals) to make it clear that he was running without approval. We felt we had to act in some way, to retain community trust.

Since I'm here, this seems as good a place as any to point out that Betacommand's reapplication for bot priveledges at Wikipedia:Bots/Requests for approval/BetacommandBot has now been closed and archived. Interested parties will find a list of his current approvals at that venue. --kingboyk 12:47, 17 April 2007 (UTC)[reply]

Betacommand desysopped

3) For misuse of admin tools in tandem with failure to follow bot policy, Betacommand is desysopped.

Comment by Arbitrators:

I think this is a possibility that should be considered. I wonder if this user still has the communities trust. Paul August ☎ 16:58, 2 April 2007 (UTC)[reply]

At the moment there's nothing in the evidence or the workshop to recommend such a course. Mackensen (talk) 19:15, 2 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Not advocating, but it's on people's minds. Milto LOL pia 08:50, 30 March 2007 (UTC)[reply]

~~I don't think this is a good idea, the benefits of keeping Betacommand sysopped outweigh the negatives Ryanpostlethwaite contribs/talk 18:56, 30 March 2007 (UTC)~~ See bottom of page. Ryan Postlethwaite 20:53, 20 April 2007 (UTC)[reply]

I strongly oppose this remedy. Nothing has called for such a measure. —METS501 (talk) 05:27, 2 April 2007 (UTC)[reply]

Way too harsh. Being removed from WP:BAG and being prohibited from using adminbots already covers anything this remedy could accomplish. --Cyde Weys 00:41, 3 April 2007 (UTC)[reply]

If Betacommand were not already an admin I'd certainly oppose an RFA candidacy from him. In retrospect, his past RFA should not have passed, based on communications problems that were evident at the time (see the few oppose votes). Desysopping is traditionally a bigger deal than sysopping so (at least til I've thought about it more) I won't go as far as to call for desysopping, but I don't oppose it. This is partly because Betacommand's more destructive actions didn't involve sysop bits. We may need technical measures against this type of high speed editing since such incidents have happened before. 64.160.39.153 15:10, 9 April 2007 (UTC)[reply]

After considerable reflection on the nature of the incidents and their wide spread, and after much interaction with Betacommand in which he has shown a persistent propensity for rash judgements, I don't think he has the skills required of an administrator. --Tony Sidaway 08:32, 14 April 2007 (UTC)[reply]

I concur that he lacks the judgment to be an effective admin. This has become obvious to many; this is why people were calling for a community "vote of no confidence". Friday (talk) 16:26, 14 April 2007 (UTC)[reply]

The many - who exactly ? -- -- Nick^t 16:31, 14 April 2007 (UTC)[reply]

Friday, you could be right, but that isn't the way we do things here. I think that such a conclusion requires a sober deliberation. Community votes of no confidence are easily got up without evidence, and reak of moral panic and mob justice, neaither of which are much use in decision-making, This arbitration case is about the facts, and the facts suggest an unsuitedness to decision-making concerning bots and administrative actions.. --Tony Sidaway 16:35, 14 April 2007 (UTC)[reply]

I've thought long and hard about this and I don't believe I can support desysopping at this time, despite the seriousness of some of the evidence presented in this case for the following reasons

a) Betacommand remains active and has carried out around 50 administrative actions over the past week (about the same as I've performed) and over a hundred actions from the time this arbitration case was 'convened', I've taken the time to look through them all (albeit not looking through all the deleted articles) and I can't see anything I would have done differently. This leads me to believe that the 'success' rate for Betacommand's admin actions is close to 100%, and there looks to be a definite improvement in the quality of edit summaries, they appear to be more accurate and useful, so for that reason I think with Betacommand showing signs of improvement there would be no benefit to the project in desysopping, rather, the project would suffer a net loss. This could be something being done to appease the ArbCom so regular checking of Betacommand's admin actions over the next few months would be a good idea, if there is any suggestion of appeasement.

b) There has been considerable upheaval with regards to username blocking over the past 2 weeks, WP:RFC/U has been nominated for deletion and has seen 2 serious reorganisations in this period, the deletion discussion showed considerable dis-satisfaction at current policy, the RFC/U system and the way administrators block potentially offensive or unacceptable usernames, especially those with no edits. It's clear that some administrators take pre-emptive action and block potentially unacceptable usernames before they edit and disable autoblocking, whilst some, like me prefer to see some edits to tell if we've got a good contributor to nurture or a vandal to block with autoblock switched on. I think Betacommand has been caught up in the username discontentment at this time and that behaviour that was previously tolerated is rapidly becoming unacceptable. I removed few username reports from AIV the other day because they had no edits and I was basically lambasted for not blocking these accounts which hadn't edited. -- Nick^t 21:17, 14 April 2007 (UTC)[reply]

Ludicrous. Virtually all of the evidence is about bot use. Other than the admin bot issue, which I think we've established is a bot issue more than an admin issue and (as I tried to show in my section on the evidence page) not unique to Betacommand, what grounds are there for desysopping? Chick Bowen 23:19, 14 April 2007 (UTC)[reply]

I could support a desysopping on principle; however, there doesn't seem to be evidence to warrant it. I believe that banning him from using scripts on his main account, and forcing his bot to, per bot policy, re-submit for any and all tasks where such is required, would be sufficient. Ral315 » 19:57, 17 April 2007 (UTC)[reply]

Adminship isn't a trophy, and I don't believe the project would benefit from Betacommand being desysopped, nor that the situation warrants it. --kingboyk 10:34, 20 April 2007 (UTC)[reply]

I strongly oppose this remedy. I have critisised Betacommand on numberous occasions, I even started the RfC, but desysopping Beta would be a great loss to the community. Of cause betacommand has ballsed up, but I'm sure all of us have in our time here. With regards to the username issue, Betacommand has stopped username blocks, and he did do as soon as the RfC was filed. It seams to me, that the semi automated tools he used simply had minor bugs in, beta didn't set out to harm the project, he was trying to help it, as he does with everything he does. I think it's clear now that Betacommand knows he made a mistake and should be punished to some degree, but there are many other proposed remedies which will give a much greater benefit to the project, nobody wins if Betacommand is desysopped. I urge the arbitration commitee to decide on a less severe remedy. Ryan Postlethwaite 20:53, 20 April 2007 (UTC)[reply]

Betacommand placed on administrative parole

4) Betacommand is placed on administrative parole for a period of one year.

4.1) Betacommand is placed on administrative parole for a period of one year. In this time all of his administrator functions are open to scrutiny. If further evidence of abuse occurs, The arbitration committee will re-open the case immediately.

4.2) Betacommand is placed on administrative parole for a period of one year. If any further evidence occurs regarding abuse of adminstrator tools, or unauthroised script or bot use, he may be blocked for upto one week.

4.3)Betacommand is placed on administrative parole for a period of one year. If any further evidence occurs regarding abuse of adminstrator tools, or unauthroised automated script use, he may be blocked for upto one week. After 5 such blocks, the maximum block time is increased to a year.

4.4) Betacommand is placed on administrative parole for one year. He is required to immediately revert any administrative action if queried by another administrator. If queried by a non-administrator he is required to write a full explanation on Wikipedia:Administrators' noticeboard, and the action may be reverted by any administrator. In the event of his unavailability the reversal may be performed after discussion on Wikipedia:Administrators' noticeboard.

Comment by Arbitrators:

Comment by parties:

Proposed Ryanpostlethwaite contribs/talk 14:58, 30 March 2007 (UTC)[reply]

What is administrative parole, please? May we have a link? --AnonEMouse ^(squeak) 15:01, 30 March 2007 (UTC)[reply]

Similar to the proposal below, if there are any further cases of abuse, Arbcom are entitled to reopen the case immediately. It also means that people will scrutinise his edits, and look out for further abuse. It is a less severe punishment to desysopping. Ryanpostlethwaite contribs/talk 15:04, 30 March 2007 (UTC)[reply]

Thanks. Support; best idea I've seen so far. --AnonEMouse ^(squeak) 16:03, 30 March 2007 (UTC)[reply]

Comment - Support, this I think this is a very appropriate option. -- Chrislk02 (Chris Kreider) 02:26, 3 April 2007 (UTC)[reply]

Comment by others:

Administrative parole should be a specific remedy. The words by themselves don't mean anything. Under what circumstances, by whom, and with what measures, could the parole be invoked? --Tony Sidaway 16:06, 30 March 2007 (UTC)[reply]

Leave it with me and I'll try and come up with something more specific Ryanpostlethwaite contribs/talk 16:10, 30 March 2007 (UTC)[reply]

Proposal 4.1 now made Ryanpostlethwaite contribs/talk 16:16, 30 March 2007 (UTC)[reply]

Hasn't arbcom been rejecting admin parole lately? Milto LOL pia 16:07, 30 March 2007 (UTC)[reply]

Not sure on other cases, but to me, in this case, it isn't something which merits desysopping at present, but it is something that needs to be looked out for in the future Ryanpostlethwaite contribs/talk 16:10, 30 March 2007 (UTC)[reply]

4.1 isn't administrative probation/parole. Probation/parole in the Wikipedia context implies subject to immediate sanction by administrators for disruption (blocking, banning, etc). The process described here is "continued jurisdiction." --Tony Sidaway 16:52, 30 March 2007 (UTC)[reply]

4.2 and 4.3 proposed (adapted from other arbcom cases). I think it brings clarity per Tony. Ryanpostlethwaite contribs/talk 09:12, 3 April 2007 (UTC)[reply]

4.2 and 4.3 are moves in the right direction but they're a bit vague and in my opinion they're only recipes for another visit to arbitration. I've proposed 4.4 which I think should help to deal with the main problem. Administrators are reluctant to reverse another's administrative action, and proposal 4.4 is intended to deal with that problem, and by doing so to enable Betacommand to perform his mostly excellent work. --Tony Sidaway 23:55, 4 April 2007 (UTC)[reply]

4.4 is excessive, particularly "[h]e is required to immediately revert any administrative action if queried by another administrator." (emphasis added) Responding in good faith or taking the dispute to the noticeboard should be sufficient. Newyorkbrad 00:55, 6 April 2007 (UTC)[reply]

I agree that it may be excessive. It's just my attempt to make sense of the concept of administrative parole in the context of this case. Regard it, if you like, and taken along with its associated enforcement clause, as an illustration of the mechanics of this kind of remedy. A less draconian administrative parole could conceivably be written; I just haven't thought of a suitable one yet. --Tony Sidaway 07:51, 6 April 2007 (UTC)[reply]

Betacommand strongly cautioned

5) For use of inappropriate scripts and username blocks, Betacommand is strongly cautioned. Any further abuse may result in desysopping

Comment by Arbitrators:

Comment by parties:

Proposed. Ryanpostlethwaite contribs/talk 15:00, 30 March 2007 (UTC)[reply]

Comment by others:

I believe all the users involved with this arbitration case are administrators, so I would like all the involved parties to be cautioned and reminded they should be contacting a fellow admin to discuss problems before posting on prominent noticeboards and such, should the ArbCom find lapses in their behaviour. I believe, away from the specifics of this case, there seems to be a serious lack of communication between some administrators when reviewing other administrators actions. I'm not suggesting cabalism, but a little more collegialism would help things out around here. -- Nick^t 18:01, 30 March 2007 (UTC)[reply]

You should probably propose that as a separate item. Though I'm not overly convinced, I certainly agree there was some haste involved and digging up old issue didn't help, but how many times do things get discussed quietly before a greater visibility is required? --pgk 19:07, 30 March 2007 (UTC)[reply]

I'm not an admin and was involved in trying to get the bot stopped and in the subsequent ANI discussion. I'll try to post some more later but have to do RL stuff now. 64.160.39.153 15:12, 9 April 2007 (UTC)[reply]

Addresses the wrong problem. It's not that he was using bots; it's not that the bots had bugs; it's that the tasks he programmed the bots to do were bad ideas and he kept doing the same stuff over and over despite repeated drama. That is plain consistently bad judgement, whether or not bots were involved. 64.160.39.153 04:40, 11 April 2007 (UTC)[reply]

Betacommand temporarily desysopped

6) For poor judgement in making administrative descisions, Betacommand is temporarilly desysopped for a period of 20 days. After which, his sysop tools will be restored.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed. Because many of the problems with betacommands actions have been a tandum between admin actions and the use of scirpts, taking the admin tools away for a short period of time will no doubt make Betacommand think before he acts when he hasn't got the tools, this will hopefully help him judge things better in the future. Ryanpostlethwaite contribs/talk 11:23, 3 April 2007 (UTC)[reply]

Never like these sort of remedies either. As we say elsewhere adminship is not a reward, badge of honour etc. The simple question (in relation to retention of sysop privileges) should be is Betacommand trusted to use good judgement in the future using the tools. If he isn't then he shouldn't have the tools, if he is then this remedy serves little purpose. --pgk 14:40, 3 April 2007 (UTC)[reply]

I agree with pgk. I appreciate that a temp desysop could send a "be more careful" message, but he's already gotten many "please be more careful" messages from a variety of other editors. Friday (talk) 14:46, 3 April 2007 (UTC)[reply]

I can appreciate that the deterrent effect of temporary desysopping may make it attractive to arbitrators, who sometimes find themselves needing to send a clear message to the community. I don't think this is that kind of case, though. Wikipedia is intended to thrive despite having administrators and other powerful users who are prone to errors, If Betacommand's history indicates that he is chronically unsuited to adminship, the bit should be removed. If not, it should remain. Taking it away for a few days isn't going to have any useful effect. --Tony Sidaway 07:59, 6 April 2007 (UTC)[reply]

Likewise, I'm not fond of this type of remedy. I don't like "punative" decisions, though I (cautiously) recognize they may be sometimes necessary. This seems to be a punishment, and I don't like to punish people, period the end. It's the bleeding heart liberal side of me. I think a more elegant solution can be found, though I'm sad to say that at this point I can't think of one. I'll continue thinking, though. It comes down to, for me, whether or not we trust the user with the tools. If we don't trust him the first day of "suspension", why would we trust him on the twentieth, or thirtieth, or one hundredth? If someone can demonstrate to me how this type of action would be helpful, I'm pleased to listen, but until it can be demonstrated to be more than punative, I have ethical issues with it. Philippe 20:43, 10 April 2007 (UTC)[reply]

I know you've put quotes around the punative, so maybe we are along the same lines, but my problem with this is that I don't necessarily see it as punative. Adminship isn't supposed to be a privilege in that sense, block him for 20 days so he can't waste many a happy hour doing speedy deletions and following up on the inevitable complaints of those who believe their local band is indeed important enough. As above though I of course agree with your conclusion that this comes down to a basic question of trust --pgk 22:12, 11 April 2007 (UTC)[reply]

An enforced cooling-period sends a strong message to both the user and the community and gives the user some time to reflect. In this case, the scope of the findings may genuinely require such time. We often ask editors to walk away from a problem article for a while and edit elsewhere. ArbCom has even mandated this. Why not ask a user to walk away from certain problem tools for a while, and edit elseways? And even have Arbcom mandate it. I would consider this a sensible action by ArbCom. Jd2718 13:23, 21 April 2007 (UTC)[reply]

Betacommand admonished

7) Betacommand sought to address problems on a proactive and systematic basis, such as by setting up a system that he believed would enable him to block accounts that were highly likely to become vandal accounts based on their usernames, and by creating a script to delete what he believed were spam links. Such systematic efforts to address these matters, which are serious issues for the project, are commendable. However, Betacommand repeatedly implemented the systems he designed while operating with undue haste, resulting in significant numbers of bad or questionable blocks and inappropriate link deletions, and creating serious concern through multiple discussions among a number of editors and administrators; he then in several instances failed to satisfactorily address the concerns raised. Under the circumstances, Betacommand is admonished:

(A) To implement username blocks only in cases where:

(1) the username, on its face, represents an obvious violation of the username policy;

(2) the account, based on the username, was plainly created by an identifiable vandal or troll, and in this case, to briefly indicate the reason for this conclusion in an edit or block summary; and

(3) in other cases, after seeking consensus on WP:RFC/N.

(B) To delete external links only in situations where a violation of the external links policy is clear or the linked site appears on the Meta blacklist, and after removing any link, to ensure that the sense and formatting of the article in question have not been damaged;

(C) To abide by the bot policy and to any policy that may evolve from further community discussion concerning bot-assisted edits and the use of scripts;

(D) To respond promptly and in good faith to reasonable questions and criticisms concerning his administrator actions; and

(E) That repetition of the conduct that led to this arbitration case may result in further action, potentially including desysopping, upon further application to the Arbitration Committee.

7.1) (alternative) Betacommand is admonished to make every effort to communicate his actions and reasons for taking them clearly. This is especially important where Wikipedia policy is still developing.

Comment by Arbitrators:

Comment by parties:

Support. Addresses everything I had in mind bringing this case, without the immediate guillotine. NYB for arbcom!--AnonEMouse ^(squeak) 19:27, 4 April 2007 (UTC)[reply]

Comment by others:

Proposed. I think this summarizes where we are with respect to the principal concerns that have been raised. Newyorkbrad 19:20, 4 April 2007 (UTC)[reply]

As a matter of procedure, this seems to combine findings of fact and a remedy. Thatcher131 19:33, 4 April 2007 (UTC)[reply]

The formatting might be an attempt to put the admonition into a context of recognizing the subject's good faith and positive contributions along with the negatives, in the hope of not losing this contributor's services altogether (cf. e.g. Wikipedia:Requests for arbitration/Marudubshinki). Then again, it might just be a connivance to put everything I have to say in one place on the workshop page so it doesn't get lost. Newyorkbrad 19:38, 4 April 2007 (UTC)[reply]

Needs legs, as noted by Thatcher131, but I agree totally with this proposal. --Random832 20:39, 4 April 2007 (UTC) -- One thing should be changed: ... was plainly created by an identifiable vandal or troll, and in this case, to briefly and neutrally indicate the reason for this conclusion in an edit or block summary; ... - in case someone innocently chooses such a name, it'd be better to simply explain that there is a vandal who uses names resembling the one the user chose, rather than accuse the user (who may be a new user with no knowledge of the history) off the bat of being a vandal. --Random832 20:43, 4 April 2007 (UTC)[reply]

7 is far too specific. Making an admonishment so specific in a case like this overlooks the fact that there is evidence that all of the problems are due to one or two signal failings in Betacommand's way of approaching adminship. I've proposed 7.1 and commend it to the arbitrators as a way of addressing Betacommand's ongoing failure of communication. It goes without saying that if there are further unaddressed or inadequately addressed problems in the future this could lead to further arbitration, and it is important not to state this because it gives the misleading impression that arbitration is a closed process. The committee can and sometimes does re-open a case if a remedy isn't working. --Tony Sidaway 23:40, 4 April 2007 (UTC)[reply]

Agree with Tony Sidaway; 7.1 is far preferable to 7. Maybe could add some words saying to be more heedful of requests to stop an ongoing action and discuss it. 64.160.39.153 07:35, 13 April 2007 (UTC)[reply]

Mentorship

8) Betacommand should enter a mentorship arrangement under a few other admins and bot writers TBD. If he's thinking of doing something potentially disruptive, especially with a bot, he should seek their advice before doing it. If they ask him to stop an ongoing action he should stop it immediately and unconditionally, and discuss it and not resume it without their agreement. The mentors should be responsive to community and BAG consensus about whether to let disputed actions resume. They should also respond to intervention requests from community members in the event that a member doesn't get a satisfactory response from Betacommand about something that Betacommand is doing. Betacommand should still nonetheless make particular efforts to be more responsive to community members in general than he has been in the past, so that intervention by mentors is rarely needed. 64.160.39.153 17:40, 14 April 2007 (UTC)[reply]

Comment by Arbitrators:

This is not a remedy that the ArbCom has the power to institute or mandate. Paul August ☎ 20:51, 19 April 2007 (UTC)[reply]

Comment by parties:

Support, with the rather important precondition that a specific mentor be found and agree. --AnonEMouse ^(squeak) 17:27, 18 April 2007 (UTC)[reply]

I have no objections to mentor ship. Betacommand ^{(talk • contribs • Bot)} 17:48, 18 April 2007 (UTC)[reply]

Comment by others:

Proposed. The idea is to create a mechanism for stopping Betacommand's ongoing errors of judgement before they get out of hand. 64.160.39.153 17:40, 14 April 2007 (UTC)[reply]

This is too wordy and too prescriptive, but I think we all get the idea and it's worth considering. There has been at least one highly successful mentorship in the past--that of Cool Cat managed by three administrators including me. This wouldn't be a bad idea but the choice of mentor is not easy to make. We'd need several administrators, at least one of whom would be an expert on bot operation. I think this would be worthwhile. Betacommand makes errors but he does often consult others and listen to those whom he consults. --Tony Sidaway 17:50, 14 April 2007 (UTC)[reply]

Feel free to rewrite. Hopefully this would be a friendlier and less stressful mentorship than in the cases where someone was actively trying to abuse the encyclopedia. Betacommand is a well-intentioned editor who (like most of us) has stronger skills in some areas than others. He's good at programming these bots but has repeatedly been in need of guidance about what it's appropriate to program the bots to do. 64.160.39.153 23:54, 14 April 2007 (UTC)[reply]

to Paul August - Arbcom has put editors under mentorship several times in the past, though (other than possibly Cool Cat) I don't know of any instances where the editor being mentored was an admin at the time. See WP:Mentorship. 75.62.7.22 05:18, 24 April 2007 (UTC)[reply]

Referred to the Bot approvals group

10) The Bot approvals group is requested to clarify bot policy with respect to administrators' use of automated and semi-automated tools on their admin accounts.

Comment by Arbitrators:

Comment by parties:

Comment by others:

It is clear that some admins use scripts to speed up administrative tasks, like orphaning and deleting images, speedy deletions, and maybe other tasks. It is not clear whether this is permitted by bot policy. Issues that arose in this case include the speed of edits (how many edits per minute may an admin make with the use of a script without a bot-flagged account), the level of automation permitted, and debugging. Thatcher131 05:15, 15 April 2007 (UTC)[reply]

As above, I would suspect this is jumping the gun. The first question should be does the community support the BAG approving admin bots for operation. At the moment a BOT would always use an account different to the operator of that bot. In these instances the accounts are the same so the distinction between which actions are by the admin and which by an automated process are not necessarily clear. --pgk 08:55, 15 April 2007 (UTC)[reply]

I don't think that BAG should be allowed to hand out adminbits, thats something that a wider community needs to discuss. From the protectionbot RFA, I think the community is willing to accept a well done and prepared adminbot proposal, but it would need to be open source (one of the objections) and the task limited to one area. For any new tasks a new bot should be proposed. (this was another objection on the RFA that the task was not well defined, and the bot operator did not come out and state that he would not expand the bot's scope, by proposing ideas to BAG) —— Eagle101 ^{Need help?} 15:19, 16 April 2007 (UTC)[reply]

If an administrator requests their bot has administrative permissions, I have no problems with BAG authorising this, provided the bot passes all current and any future stringent safety measures to prevent deletions, merges and protections which are unwanted and unauthorised. It's probably unlikely to happen, but I would totally oppose any non admin being given admin permissions for their bot without first going through a standard RFA. -- Nick^t 15:28, 16 April 2007 (UTC)[reply]

I don't really mind, I just don't see BAG can expand its remit to such authorisations without the community granting it that remit. --pgk 16:34, 16 April 2007 (UTC)[reply]

At present there is really no guidance from the bot group on use of automated and semi-automated tools on admin accounts. Any guidance would be better than none. For example, Admins may not use automated tools on their admin account without approval. (strict) or Admins may use semi-automated tools (requiring manual confirmation of each action) and equip them to perform deletions, as long as they do not make more than X edits per minute. Exceeding this rate requires approval and a flag. (loose) More on talk page. Thatcher131 16:00, 16 April 2007 (UTC)[reply]

I don't think that advice is for BAG to give. If admins can use the tools on their account etc. are issues for the community to decide, not the members of BAG, which just provides some oversight to the approval process, the ultimate authority and general approval for bots existing at all is from the community. If the community wishes to give some broad approval for the use of semi-automated or fully automated processes on an admin account, then they can do so, if they want to assign a similar oversight role to BAG for those then I'm sure we can come up with some guidelines after discussion with the devs, but I can't see BAG being able to unilaterally decide on that issue for the community.--pgk 16:34, 16 April 2007 (UTC)[reply]

I understand your concern but I think this is a case for being bold. The BAG has the expertise regarding coding and debugging bots and scripts and edit rates. While the community is divided on dedicated sysop-bot accounts, it already tolerates admin-equipped scripts run by existing admins as long as they don't make waves. I suggest having an expert-level discussion, then boldly changing the bot policy. The alternative is to go to the village pumps etc. and trying to find an audience, most of whom don't know or don't care about bots, or to go to RFA, except that really isn't applicable here since we are mostly talking about manually confirmed script-assisted editing, not fully autonomous adminbots. Thatcher131 16:42, 16 April 2007 (UTC)[reply]

It's be bold, but don't be reckless. Given that the various RFAs for bots have failed or been withdrawn trying to short circuit things to me would be the latter. If the community broadly accepts certain admin bot activity (or semi-automated bot) then getting a rough consensus such as at the village pump shouldn't be a problem. Regardless even if BAG disagree and do wish to just take this on, I can't see this as being something for ARBCOM to mandate. --pgk 17:04, 16 April 2007 (UTC)[reply]

Do keep in mind that the Protectionbot RFA did have a chance of passing, had werdna not made the mediawiki improvement. Only thing that could be done to improve matters would be to have the adminbot (before going to RFA be open source, but thats another debate for another day). —— Eagle101 ^{Need help?} 19:56, 16 April 2007 (UTC)[reply]

Yes it did, (though there is a separate question about if those so inclined would be better building mediawiki extensions for some things rather than admin bots). Others have failed. Realistically it still says it is an open issue, perhaps it is more to the form of the other failures, perhaps the range of tasks suitable for full automation is that the community would want broader discussions on them, whilst being happy to hand off approval for semi-automatic elsewhere. I personally perceive this as something far from universally accepted as a good thing. --pgk 21:06, 16 April 2007 (UTC)[reply]

Betacommand placed on administrative parole

9) Betacommand is placed on administrative parole for a period of 1 year. If there are further occurances of innapropriate script use or inappropriate blocks, he may be blocked for upto 1 week. After the 3rd block, Betacommand will be desysopped.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed (although may need refactoring). This remedy is still protective for the encyclopedia, but allows Betacommand to stay sysopped. It provides a clear stratedgy for dealing with further occurances of abuse by Betacommand. With the proposal, I would suggest that after the 3rd block (if it occurs) it is brought to the main request for arbitration page and the arbitrators simply vote to confirm the desysopping. Ryan Postlethwaite 22:44, 23 April 2007 (UTC)[reply]

This is a positive contribution. However, it does not address the poor (or complete lack) of communication with users. Further, 3 more blocks is 2 too many. At this point he gets it or he doesn't. After refactoring, this might work well in combination with a temporary period of editing without admin tools. Jd2718 23:35, 23 April 2007 (UTC)[reply]

Template

9) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

9) {text of proposed remedy}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Proposed enforcement

Enforcement of Administrative parole

1) Should Betacommand fail to reverse an administrative action when required to do so, or fail to put an explanation on Administrators' noticeboard when required to do so, he may be blocked by any administrator, for up to two weeks in the case of repeat offences.

Comment by Arbitrators:

Comment by parties:

Comment by others:

Related to proposed remedy 4.4. --Tony Sidaway 00:01, 5 April 2007 (UTC)[reply]

See my comment above re proposed remedy 4.4. Newyorkbrad 00:55, 6 April 2007 (UTC)[reply]

Mandatory waiting time

2) When performing admin actions, to show enough attention has been payed to these actions, Betacommand must take at least 5 seconds considering each of them.

Comment by Arbitrators:

Comment by parties:

Move to dismiss this, you have no clue how long I work on an issue before making an admin action. Like I have said in other places I could spend 1-2 hours looking over a SSPA case and then proceeded to block 9 users with a period of 6.666 seconds between them. that doesn't show the effort that I put into place prior. I take care with all my admin actions. Betacommand ^{(talk • contribs • Bot)} 00:53, 12 April 2007 (UTC)[reply]

Comment by others:

proposed Although this may be tedious, the admin tools require at least some judgement and have the power to cause a lot of disruption (which is why they are restricted of course), so this shouldn't be too much to ask. Think before you click. Tinus 21:53, 11 April 2007 (UTC)[reply]

I don't see how it addresses the issue. If he's careful, I suspect nobody much cares how fast or slow he goes. Friday (talk) 21:56, 11 April 2007 (UTC)[reply]

Practically unenforceable, use a bot put a 5 second delay in. This comes down to the same basic concept, either we trust him to use good judgement in the future (which would in part mean considering individual items for an appropriate amount of time be that 1 second for a G8 deletion or 1 hour for a complex afd close) or we don't --pgk 22:16, 11 April 2007 (UTC)[reply]

5 seconds? I'm not sure if someone can make a valued judgement on an edit in 5 seconds Ryanpostlethwaite contribs/talk 00:59, 12 April 2007 (UTC)[reply]

Also agree with Betacommand, why should he be limited to blocks if he's carefully looked over a SSPA case? Ryanpostlethwaite contribs/talk 01:02, 12 April 2007 (UTC)[reply]

If accepted this would be a remedy, not enforcement. I'd also add that it's unenforceable. --Tony Sidaway 08:17, 13 April 2007 (UTC)[reply]

Template

3) {text of proposed enforcement}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

4) {text of proposed enforcement}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

5) {text of proposed enforcement}

Comment by Arbitrators:

Comment by parties:

Comment by others:

Analysis of evidence

Place here items of evidence (with diffs) and detailed analysis

High speed blocking

n) Betacommand has used automated tools to enable rapid blocking, see Wikipedia:Requests_for_arbitration/Betacommand/Evidence#Rapid_Blocking. While this tool was apparently a manually operated script and not a true bot [183], the speed of these blocks raises the question of whether there is time to exercise an appropriate level of analysis and discretion.

Comment by Arbitrators:

I've done high-speed checkuser blocks in a similar fashion. Mackensen (talk) 00:06, 5 April 2007 (UTC)[reply]

Comment by parties:

Comment by others:

Thatcher131 00:55, 3 April 2007 (UTC)[reply]

If this was a series of pre-selected users or IPs being blocked, then the speed of blocking doesn't indicate the time spent analysing and selecting the users. --Tony Sidaway 01:49, 3 April 2007 (UTC)[reply]

True. That's why I listed it here rather than as a finding. Thatcher131 01:54, 3 April 2007 (UTC)[reply]

At one point I was doing a WP:SSPA case and spent an hour looking into it and I blocked/unblocked/reblocked them all in about 3 minutes (there was an error in the original block reason). Betacommand ^{(talk • contribs • Bot)} 01:57, 3 April 2007 (UTC)[reply]

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

Template

Comment by Arbitrators:

Comment by parties:

Comment by others:

General discussion

Comment by Arbitrators:

Comment by parties:

Comment by others: