Wikipedia:Arbitration/Requests/Case/Betacommand 3/Proposed decision

Main case page (Talk) — Evidence (Talk) — Workshop (Talk) — Proposed decision (Talk)

Case clerk: TBD Drafting arbitrator: TBD

After considering /Evidence and discussing proposals with other arbitrators, parties, and editors at /Workshop, arbitrators may make proposals which are ready for voting. Arbitrators will vote for or against each provision, or they may abstain. Only items which are supported by an absolute majority of the active, non-recused arbitrators will pass into the final decision. Conditional votes and abstentions will be denoted as such by the arbitrator, before or after their time-stamped signature. For example, an arbitrator can state that their support vote for one provision only applies if another provision fails to pass (these are denoted as "first" and "second choice" votes). Only arbitrators and clerks may edit this page, but non-arbitrators may comment on the talk page.

For this case there are active arbitrators. support or oppose votes are a majority.

Majority reference

Abstentions	Support votes needed for majority

If observing editors notice any discrepancies between the arbitrators' tallies and the final decision or the #Implementation notes, you should post to the clerk talk page. Similarly, arbitrators may request clerk assistance via the same method, or via the clerks' mailing list.

Proposed motions

Arbitrators may place proposed motions affecting the case in this section for voting. Typical motions might be to close or dismiss a case without a full decision (a reason should normally be given), or to add an additional party (although this can also be done without a formal motion as long as the new party is on notice of the case). Suggestions by the parties or other non-arbitrators for motions or other requests should be placed on the /Workshop page for consideration and discussion.
Motions have the same majority for passage as the final decision.

Template

1) {text of proposed motion}

Support:

Oppose:

Abstain:

Comments:

Proposed temporary injunctions

A temporary injunction is a directive from the Arbitration Committee that parties to the case, or other editors notified of the injunction, do or refrain from doing something while the case is pending.

Four net "support" votes needed to pass (each "oppose" vote subtracts a "support")
24 hours from the first vote is normally the fastest an injunction will be imposed.

Template

1) {text of proposed orders}

Support:

Oppose:

Abstain:

Comments:

Proposed final decision

Proposed principles

Determining the value of edits

1) The ultimate authority to determine whether any particular edit, series of edits, or type of edit is an improvement or a detriment to the encyclopedia rests with the editorial community.

Support:

1. Proposed. For the sake of simplicity, I have omitted the standard provisos to this (e.g. legal constraints, WMF mandates, etc.). Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. Possibly could be copyedited to include a qualification such as 'in general'. PhilKnight (talk) 23:45, 3 January 2012 (UTC)
3. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
4. I guess this has to be said. AGK [•] 01:24, 4 January 2012 (UTC)

Oppose:

1. That's only true to a point, and I have serious concerns that this principle can be quoted in the future. In practice, the community is the ultimate authority in normal situations. It's not an issue in this case, of course, but Jclemens is right below that there are "higher" rules that no amount of consensus can rule against. Even if 100% of editors decided against an article being neutral, for instance, they'd still be wrong. — Coren ^(talk) 16:24, 4 January 2012 (UTC)
2. Concur with Coren. In addition to the "standard provisos" is the fact that community-developed policies take precedence over whichever small section of the community happens to review any particular edit. Risker (talk) 02:52, 5 January 2012 (UTC)
3. Per Coren really. Applies in most cases but this is one of those vexed scenarios where the principle is too simple. Casliber (talk · contribs) 08:54, 6 January 2012 (UTC)
4. Also per Coren,  Roger Davies ^talk 12:24, 12 January 2012 (UTC)
5. I think it's nice in theory but practically is a bit too ironclad. Der Wohltemperierte Fuchs^(talk) 15:17, 12 January 2012 (UTC)
6. SilkTork ^{✔Tea time} 22:34, 12 January 2012 (UTC)
7. Too ironclad. Courcelles 16:46, 19 January 2012 (UTC)

Abstain:

Comments:

Uncomfortable with wording - "ultimate authority" in particular. The community deal with editorial matters, though who is the final judge of the value of an edit? Perhaps the reader of the article? The reader does not have to be part of the community to make a judgement on value. SilkTork ^{✔Tea time} 00:02, 4 January 2012 (UTC)

Until we can effectively find out what our readers think about particular edits, relying on them as an authority when evaluating the value of those edits seems impractical. Kirill ^{[talk] [prof]} 01:11, 4 January 2012 (UTC)

I'm not willing to support this without some explicit provision that this is not an absolute statement, as mentioned in Kirill's support vote. Courcelles 01:22, 4 January 2012 (UTC)

I'm on the fence with this one as well. Can the community decide to abandon the pillars, yet still expect support from the WMF? In one sense, no, we certainly cannot. Still, nothing that dramatic is at issue in this case, so there is probably some language that would not raise such concerns... I'm just not exactly sure how to best state it at the moment. Jclemens (talk) 03:49, 4 January 2012 (UTC)

I'm reluctant to spend too much more time debating this principle, because it's highly abstract, and threatens to take more attention away from the fact-specific issues we need to focus on in this case, which are whether Betacommand violated his sanctions, whether there are aggravating or mitigating factors, and what the remedy should be. To move forward, though, I suggest that we add "Subject to the project's fundamental principles and Wikimedia Foundation mandates ..." at the outset of the principle. ("... or legal requirements" could also be added but isn't actually necessary, as the Foundation expects its projects to abide by applicable laws, though which laws are applicable isn't always clear). Newyorkbrad (talk) 01:24, 6 January 2012 (UTC)

Community sanctions

2) The community has the authority to impose sanctions (such as editing restrictions or bans) on any user whose edits are a detriment to the encyclopedia.

Support:

1. Proposed. As above, the standard provisos (e.g. WMF staff, etc.) are omitted. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. PhilKnight (talk) 23:47, 3 January 2012 (UTC)
3. Yes, this is clearer than 1. SilkTork ^{✔Tea time} 00:02, 4 January 2012 (UTC)
4. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
5. Courcelles 01:21, 4 January 2012 (UTC)
6. Blindingly obvious, but necessary as an accessory to 1. AGK [•] 01:24, 4 January 2012 (UTC)
7. Jclemens (talk) 03:08, 4 January 2012 (UTC)
8. Ayup. — Coren ^(talk) 16:25, 4 January 2012 (UTC)
9. Actually, I don't see that the "standard provisos" would interfere with this principle. Risker (talk) 02:53, 5 January 2012 (UTC)
10. Generally true statement. Newyorkbrad (talk) 01:25, 6 January 2012 (UTC)
11. Casliber (talk · contribs) 08:54, 6 January 2012 (UTC)
12. Mailer Diablo 02:35, 8 January 2012 (UTC)
13.  Roger Davies ^talk 12:24, 12 January 2012 (UTC)
14. Wait, really? </sarcasm> Der Wohltemperierte Fuchs^(talk) 15:17, 12 January 2012 (UTC)
15. Elen of the Roads (talk) 22:14, 12 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Review of community sanctions

3) As stated in §1.1 of the arbitration policy, the Arbitration Committee is responsible for "hear[ing] appeals from blocked, banned, or otherwise restricted users", including users subject to sanctions imposed by the community.

In certain circumstances, the Committee may overturn or reduce a sanction imposed by the community. Such circumstances include, but are not limited to, cases where (1) some aspect of the community discussion was procedurally unfair, (2) the sanction imposed appears to be significantly excessive or overbroad, (3) circumstances have changed significantly since the community sanction was imposed, or (4) non-public information that should not be addressed on-wiki, such as personal information or checkuser data, is relevant to the decision.

Support:

1. Proposed. The second paragraph is taken from the Shakespeare authorship question decision. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. PhilKnight (talk) 23:48, 3 January 2012 (UTC)
3. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
4. I'm not convinced that a case decision is the appropriate venue for this decision. If the arbitration policy is not specific enough as to the circumstances in which we would reverse a community decision, then the policy should be amended. From a constitutional perspective and in my experience, passing decisions like these in a specific case is suboptimal: consider, for instance, that our expectation that e-mails will not be shared on-wiki without the permission of the sender is vested (counter-intuitively) in cases named Hkelkar 2 and Durova. However, the need to resolve this dispute (with informative principles in the final decision) is more immediately pressing. AGK [•] 01:24, 4 January 2012 (UTC)
5. Jclemens (talk) 03:08, 4 January 2012 (UTC)
6. Courcelles 03:12, 4 January 2012 (UTC)
7. It's probably worth noting that, historically, the Committee has always given a great deal of deference to community decisions (including sanctions). Tweaking, or endorsing them are also entirely valid results from decisions and – by far – the most common one. — Coren ^(talk) 16:26, 4 January 2012 (UTC)
8. Concur. Risker (talk) 02:57, 5 January 2012 (UTC)
9. Responding to AGK and SilkTork, the principle that users dissatisfied by a community sanction can appeal to the Arbitration Committee has been recognized for years. The committee has considered appeals from community-banned users for as long as I've been an arbitrator (in fact, we established the Ban Appeals Subcommittee precisely because such appeals were such a large fraction of the Committee's work). And it stands to reason that if a user can appeal to us from a community ban, then one should be able to appeal from a sanction less than a full ban (though as a practical matter we would be unlikely to overturn such a sanction unless we thought that the community discussion had misfired very badly). The vagaries of any given day on ANI are such that I would be very hesitant to leave a user sanctioned there with no avenue for review at all. Newyorkbrad (talk) 01:29, 6 January 2012 (UTC)
10. Casliber (talk · contribs) 08:54, 6 January 2012 (UTC)
11. Mailer Diablo 02:35, 8 January 2012 (UTC)
12.  Roger Davies ^talk 12:24, 12 January 2012 (UTC)

    And emphasising that although it is not mentioned in the examples above, per policy, the committee is explicitly authorised "to act as a final binding decision-maker primarily for serious conduct disputes the community has been unable to resolve". This provides broad discretion and if it requires sanctions which are not working to be vacated, so be it.  Roger Davies ^talk 10:04, 16 January 2012 (UTC)

13. We've done this previously, but we usually defer to the community in most situations because the extenuating circumstances listed do not apply to most sanctions. Der Wohltemperierte Fuchs^(talk) 15:17, 12 January 2012 (UTC)
14. We have done this. Elen of the Roads (talk) 22:16, 12 January 2012 (UTC)

Oppose:

• [Moved to abstain]. I note that the notion that ArbCom can overturn a community sanction was supported 15-0 by the Committee just 10 months ago, so this appears to be an established view; however I don't think the policy is clear on this point. I'm not convinced at the moment that the community ratified a policy that gave ArbCom the authority to overrule community consensus. My understanding is that the community gave ArbCom authority to decide matters on which there is no consensus. SilkTork ^{✔Tea time} 10:04, 5 January 2012 (UTC)

Abstain:

1. In light of NYB's clarification I am not opposing what has become accepted procedure by default, though reluctant to confirm it without more evidence that it is in line with community consensus. SilkTork ^{✔Tea time} 09:35, 6 January 2012 (UTC)

We've been asked to look at the sanctions in this case, so wording which says "When asked to consider specific community sanctions, the Committee may overturn or reduce those sanctions in certain circumstances, such as....", would be acceptable. SilkTork ^{✔Tea time} 14:12, 12 January 2012 (UTC)

Comments:

Is this wise? If the community bans someone, and the individual appeals, and the Committee feels the ban is harsh, is there no middle way? I'm not convinced that the Committee was set up to overturn the community, or to be in opposition. If a community banned individual appeals to the Committee, and the Committee feels the ban was harsh, I would prefer to see a review of the ban in which the community were involved. SilkTork ^{✔Tea time} 00:15, 4 January 2012 (UTC)

If you're talking about a case where we ask the community to reconsider a sanction it has imposed, then that's not restricted by this; the principle only addresses cases where we have the authority to overturn a sanction of our own accord. Kirill ^{[talk] [prof]} 01:13, 4 January 2012 (UTC)

• Note to AGK: Kirill is referencing the arbitration policy, which is a community-ratified policy. I don't see any connection between this principle (which is firmly rooted in a clearly-identifiable policy) and the cases you mention. Risker (talk) 02:57, 5 January 2012 (UTC)

• The second paragraph makes new rules not contained in the arbitration policy. Although the particular grounds under which we will vacate community sanctions are probably reasonable - and moreover, are probably an acceptable extension of the arbitration policy and codification of our current practice - the fact remains we are making rules in the course of a specific case. My point is that we did this previously (for instance, on sharing e-mails in Durova) in a final decision, and that I would prefer we only did so with a direct amendment to the ArbPol. Sorry for being unclear! AGK [•] 17:37, 13 January 2012 (UTC)

Recidivism

4) Users who have been sanctioned for improper conduct are expected to avoid repeating it should they continue to participate in the project. Failure to do so may lead to the imposition of increasingly severe sanctions.

Support:

1. Jclemens (talk) 03:44, 4 January 2012 (UTC)
2. Although this should really go without saying. Kirill ^{[talk] [prof]} 03:46, 4 January 2012 (UTC)
3. Yep, it should be bloody obvious. Courcelles 03:48, 4 January 2012 (UTC)
4. Indeed, patterns of improper conduct are the primary factor in determining sanctions by the Committee (and, indeed, the community). — Coren ^(talk) 16:28, 4 January 2012 (UTC)
5. PhilKnight (talk) 16:33, 4 January 2012 (UTC)
6. Risker (talk) 03:00, 5 January 2012 (UTC)
7. Useful. SilkTork ^{✔Tea time} 10:09, 5 January 2012 (UTC)
8. I might prefer a different header, as this one has a somewhat legalistic overtone, but I won't make a big deal of it. Newyorkbrad (talk) 01:31, 6 January 2012 (UTC)
9. Casliber (talk · contribs) 08:54, 6 January 2012 (UTC)
10. Mailer Diablo 02:35, 8 January 2012 (UTC)
11.  Roger Davies ^talk 12:24, 12 January 2012 (UTC)
12. Der Wohltemperierte Fuchs^(talk) 15:17, 12 January 2012 (UTC)
13. Elen of the Roads (talk) 22:17, 12 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Explain why we're considering sanctions at this level. Jclemens (talk) 03:44, 4 January 2012 (UTC)

Template

5) {text of proposed principle}

Support:

Oppose:

Abstain:

Comments:

Proposed findings of fact

Betacommand

1) Δ (talk · contribs), previously known as Betacommand (talk · contribs) and under several other names ([1]), has participated in Wikipedia since November 2005. During that time, a substantial portion of his editing has consisted of repetitive minor edits, some or all of which have been performed via the use of automated or semi-automated editing tools.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)

   I've removed "(sometimes characterized as "WikiGnoming")" per the comments below. Kirill ^{[talk] [prof]} 01:15, 4 January 2012 (UTC)

2. I'd suggest replacing 'some or all' with 'much', but that's purely stylistic. PhilKnight (talk) 23:50, 3 January 2012 (UTC)
3. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
4. With the removal of the parenthesised comment, phraseology is acceptable. AGK [•] 01:29, 4 January 2012 (UTC)
5. Yes. OK now. SilkTork ^{✔Tea time} 01:33, 4 January 2012 (UTC)
6. Works now Courcelles 01:40, 4 January 2012 (UTC)
7. Jclemens (talk) 03:09, 4 January 2012 (UTC)
8. Much of which has been productive and helpful. — Coren ^(talk) 16:29, 4 January 2012 (UTC)
9. Risker (talk) 03:25, 5 January 2012 (UTC)
10. Newyorkbrad (talk) 01:31, 6 January 2012 (UTC)
11. (agreed with removal of "wikignoming") Casliber (talk · contribs) 08:55, 6 January 2012 (UTC)
12. Mailer Diablo 03:45, 8 January 2012 (UTC)
13.  Roger Davies ^talk 12:31, 12 January 2012 (UTC)
14. Der Wohltemperierte Fuchs^(talk) 15:45, 12 January 2012 (UTC)
15. this appears to be the case Elen of the Roads (talk) 22:19, 12 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Not sure of including the phrase "WikiGnoming" - the phrase is defined as "A WikiGnome is a wiki user who makes useful incremental edits without clamouring for attention." Is that an appropriate fit for this user? SilkTork ^{✔Tea time} 00:24, 4 January 2012 (UTC)

I'm with SilkTork, given the meaning of WikiGnoming, this is not the right term to be using here. Remove the parenthetical comment, and this becomes a simple, obvious statement, though. Courcelles 00:53, 4 January 2012 (UTC)

I used Gnoming in the workshop, so it's probably my fault.Elen of the Roads (talk) 22:19, 12 January 2012 (UTC)

Evaluation of Betacommand's edits

2.1) Numerous concerns have been raised in regards to Betacommand's editing, including both concerns with the substantive content of the edits as well as concerns with Betacommand's ability and willingness to communicate the purpose and nature of the edits to other users. In light of these concerns, the community has determined that Betacommand's edits are a detriment to the encyclopedia, and has imposed a series of sanctions on Betacommand's editing.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. 2nd choice SirFozzie (talk) 01:10, 4 January 2012 (UTC)
3. Jclemens (talk) 03:11, 4 January 2012 (UTC)
4. Second choice, prefer 2.2. Newyorkbrad (talk) 01:33, 6 January 2012 (UTC)

Oppose:

1. Prefer 2.2. PhilKnight (talk) 23:54, 3 January 2012 (UTC)
2. Prefer 2.2. AGK [•] 01:29, 4 January 2012 (UTC)
3. 2.2 is far superior. Courcelles 03:14, 4 January 2012 (UTC)
4. In favor of 2.2. — Coren ^(talk) 16:33, 4 January 2012 (UTC)
5. Prefer 2.2. I'm not certain this is entirely correct. Risker (talk) 03:27, 5 January 2012 (UTC)
6. Prefer 2.2. Casliber (talk · contribs) 09:07, 6 January 2012 (UTC)
7. Prefer 2.2 - Mailer Diablo 03:45, 8 January 2012 (UTC)
8. Prefer below. Der Wohltemperierte Fuchs^(talk) 15:45, 12 January 2012 (UTC)
9. SilkTork ^{✔Tea time} 22:36, 12 January 2012 (UTC)

Abstain:

Comments:

Evaluation of Betacommand's edits

2.2) Numerous concerns have been raised in regards to Betacommand's editing, including both concerns with the substantive content of the edits as well as concerns with Betacommand's ability and willingness to communicate the purpose and nature of the edits to other users. In light of these concerns, the community has determined that some of Betacommand's editing is detrimental to the encyclopedia, and has imposed a series of sanctions on Betacommand's editing.

Support:

1. Prefer this version. PhilKnight (talk) 23:54, 3 January 2012 (UTC)
2. Yes. I have been astounded by the number of concerns raised. Regardless of the merits of each individual concern raised, the amount of drama connected to this user is unhealthy, and the user has not been helpful in reducing the drama. SilkTork ^{✔Tea time} 00:50, 4 January 2012 (UTC)
3. first choice SirFozzie (talk) 01:10, 4 January 2012 (UTC)
4. Fair enough. Kirill ^{[talk] [prof]} 01:15, 4 January 2012 (UTC)
5. Regrettably true. AGK [•] 01:29, 4 January 2012 (UTC)
6. Jclemens (talk) 03:10, 4 January 2012 (UTC)
7. Courcelles 03:13, 4 January 2012 (UTC)
8. Fair summary of the history. — Coren ^(talk) 16:33, 4 January 2012 (UTC)
9. Prefer over 2.1; I believe this is more accurate. Risker (talk) 03:27, 5 January 2012 (UTC)
10. First choice. Newyorkbrad (talk) 01:33, 6 January 2012 (UTC)
11. Casliber (talk · contribs) 09:04, 6 January 2012 (UTC)
12. Mailer Diablo 03:45, 8 January 2012 (UTC)
13.  Roger Davies ^talk 12:31, 12 January 2012 (UTC)
14. Der Wohltemperierte Fuchs^(talk) 15:45, 12 January 2012 (UTC)
15. It's the cumulative effect here. Elen of the Roads (talk) 22:20, 12 January 2012 (UTC)

Oppose:

Abstain:

Comments:

What is missing is that the community have recently been looking at reducing or relaxing the sanctions. July, where the opinion was divided - 33 in favour to 35 opposed; and Oct, which is what led to this ArbCom case. We need to show awareness that the community have been considering relaxing the restrictions, but have not reached a consensus. If we are to consider a ban because the effort required to keep Betacommand in line has become unsustainable, we'd need appropriate and balanced evidence. I have not ruled out a ban because I note the astounding amount of effort the community and ArbCom have put into keeping Betacommand in line; however, I feel the rationale for the ban should be complete, and take into account recent developments. SilkTork ^{✔Tea time} 10:26, 5 January 2012 (UTC)

Perhaps adding: "The community have recently reviewed relaxing sanctions, but have been unable to reach a consensus"? This brings the case firmly into ArbCom territory: The sanctions are not working, there is no agreement on relaxing the sanctions, where do we go from here? SilkTork ^{✔Tea time} 10:31, 5 January 2012 (UTC)

Such an addition would make sense, either to this paragraph or as a separate one, provided we can agree on a wording relatively quickly. As with principle 1, focus on peripheral issues of wording should not distract our main attention from the key fact and remedy issues in the case. Newyorkbrad (talk) 01:35, 6 January 2012 (UTC)

Lack of grounds to overturn or reduce sanctions

3) Given Betacommand's recent violations of the community sanctions, his overall history of recidivism with regards to restrictions imposed on his editing, and the lack of any evidence that the process by which the sanctions were imposed was fundamentally flawed, sufficient grounds for the Arbitration Committee to overturn or reduce the community sanctions do not exist.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. AGK [•] 01:29, 4 January 2012 (UTC)
3. Jclemens (talk) 03:11, 4 January 2012 (UTC)
4. It's not ideally structured, but factual enough. Perhaps clarify that we find no ground to overturn or alter the current sanctions? — Coren ^(talk) 16:33, 4 January 2012 (UTC)

Oppose:

1. This probably should be split in two. Firstly, a finding of fact indicating that Betacommand has violated his sanctions. Secondly, a finding to say that contrary to the above statement, ArbCom can replace or modify sanctions which have proven unsatisfactory, even if they were legitimately imposed. PhilKnight (talk) 00:20, 4 January 2012 (UTC)
2. This seems to be walking back the rationale the committee had for superseding the community ban. Do we want to go down that route? SirFozzie (talk) 01:10, 4 January 2012 (UTC)

   As below, this is intended to refer only to the current set of sanctions, not to any previous ones. Kirill ^{[talk] [prof]} 01:23, 4 January 2012 (UTC)

3. per Phil and NYB's concerns. Should be in "remedies" section anyway. Casliber (talk · contribs) 09:08, 6 January 2012 (UTC)
4. Primarily per Phil though a separate finding is not really needed now,  Roger Davies ^talk 12:31, 12 January 2012 (UTC)
5. Sounds more like a remedy than a FoF. Der Wohltemperierte Fuchs^(talk) 17:48, 12 January 2012 (UTC)
6. SilkTork ^{✔Tea time} 22:39, 12 January 2012 (UTC)

Abstain:

Comments:

As I said above, I don't want to quibble too much about wordings, but this is the crux of the case; and since I first read the draft decision a couple of days ago, there has been something about this paragraph that troubled me a little. (PhilKnight has put his finger on part of it.) I think this proposed wording may suffer from what Harold Ross and his staff at The New Yorker used to call "indirection," which they defined as introducing a new and potentially important piece of information as a by-the-way in a subordinate clause, as if assuming that the reader already knows about it. Whether Betacommand has violated his most recent set of sanctions in a significant and harmful way is one of the key things we need to decide here. I think it would be better to adopt an explicit finding saying that yes he has or no he hasn't, rather than (as appears to be proposed) adopt it implicitly in the course of moving on to the next step. Newyorkbrad (talk) 01:44, 6 January 2012 (UTC)

I accept that there are times when it makes sense to bypass a decision on a disputed or complicated factual question within a case, when there is a consensus or majority to proceed on another basis. I remain unconvinced that this is one of those times, but from the fact that no one has taken up my suggestion as to how to proceed, I gather that my colleagues feel otherwise. Newyorkbrad (talk) 03:47, 16 January 2012 (UTC)

Failure of community sanctions

4) The sanctions imposed by the community have failed to effectively resolve the various concerns raised regarding Betacommand's editing, leading ultimately to the filing of this request for arbitration.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. Perhaps 'failure' is a little strong. Could be replaced with 'have not effectively resolved the various concerns'. PhilKnight (talk) 00:03, 4 January 2012 (UTC)
3. Agree that sanctions have not worked/failed. Why they have failed is another matter. SilkTork ^{✔Tea time} 00:31, 4 January 2012 (UTC)
4. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
5. AGK [•] 01:29, 4 January 2012 (UTC)
6. Jclemens (talk) 03:12, 4 January 2012 (UTC)
7. Courcelles 03:14, 4 January 2012 (UTC)
8. — Coren ^(talk) 16:33, 4 January 2012 (UTC)
9. Re PhilKnight's comment, perhaps a header of "Continued disputes" or the like? Newyorkbrad (talk) 01:45, 6 January 2012 (UTC)
10. Casliber (talk · contribs) 09:09, 6 January 2012 (UTC)
11. Mailer Diablo 03:45, 8 January 2012 (UTC)
12.  Roger Davies ^talk 12:31, 12 January 2012 (UTC)
13. Der Wohltemperierte Fuchs^(talk) 17:48, 12 January 2012 (UTC)
14. A fair statement of fact - the dramah has not stopped. Elen of the Roads (talk) 22:21, 12 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Unban conditions not met

5) On 11 July 2009, the Arbitration Committee unbanned Betacommand conditional on his full compliance with four restrictions including that his mentors send the arbitration committee monthly reports, and he must cease editing if the mentors withdraw. The mentors user:Hersfold and user:MBisanz did not meet their commitment to the unban terms[2][3], the Arbitration Committee did not pursue this unban term, and Betacommand continued to edit. In October 2009 the Arbitration Committee invited comments from the community regarding relaxing Betacommand's restrictions. During July 2010, when some of the unban conditions were to expire, the Betacommand unban were discussed publicly in several forums, including two Arbitration Committee requests (e.g. WP:BN request by Betacommand on 11 July 2010; Clarification sought by Xeno on 20 July 2010; Amendment sought by NuclearWarfare on 25 July 2010). The community did not inquire regarding the mentoring, and the Arbitration Committee did not indicate that the mentoring condition had not been met.

Support:

1. Jclemens (talk) 21:42, 14 January 2012 (UTC)

Oppose:

1. This is all technically true, but I fail to see how it's relevant to the case at hand. Kirill ^{[talk] [prof]} 05:15, 15 January 2012 (UTC)
2. If this is suggesting that Betacommand should be banned on a technicality from the past, then I am not in favour because I would rather remedies were based on Betacommand's recent behaviour and the community's response to that. If this is intended to point out a pattern of Betacommand's behaviour, then I am not in favour because this does not relate to Betacommand's behaviour - the technical failing was that of his mentors. If it is neither of those, then I am prepared to look again. SilkTork ^{✔Tea time} 13:11, 15 January 2012 (UTC)
3. Per Kirill. PhilKnight (talk) 11:05, 17 January 2012 (UTC)

Abstain:

Comments:

Copied from John Vandenberg's work on the workshop. Jclemens (talk) 21:43, 14 January 2012 (UTC)

Kirill, I added this to demonstrate Betacommand's level of compliance to sanctions--the minimum anyone forces him to do. It also highlights past failures of supervision on our part and the community's part. SilkTork, each case regarding Betacommand is not held in a vacuum. If all previous remedies had been complied with, there would still be the issue of being unable to avoid being a drama magnet. I once had a conversation with a rather notable "computer criminal" who was describing one time when a particular Interstate was closed, and his best open route home was across a bridge, into another state, and down a parallel highway. He declined to do so on the basis that leaving the state was technically against his probation conditions and he wasn't able to contact his supervising probation officer for permission. That is the sort of compliance I would expect from someone who is a technically-savvy, but socially/communicationally challenged participant. Jclemens (talk) 17:33, 15 January 2012 (UTC)

I can see this as relevant background, although if we are going to have a background section, a good starting point would include the two prior arbitration cases, etc. I am also reluctant to mention the prior mentors critically in a decision given that they haven't been notified that their conduct was being reviewed. Newyorkbrad (talk) 03:49, 16 January 2012 (UTC)

Ongoing communication problems

6.1) Although Betacommand was counseled on communication issues during the prior cases, his manner and style of communications during disputes remains problematic. Whether intentional or not, Betacommand's communications in the current matter have frustrated involved and uninvolved editors alike.

Support:

1. Jclemens (talk) 21:56, 14 January 2012 (UTC)
2. Kirill ^{[talk] [prof]} 05:16, 15 January 2012 (UTC)
3. See comments below --Elen of the Roads (talk) 13:25, 15 January 2012 (UTC)
4. I've included Elen's amendment.PhilKnight (talk) 18:46, 15 January 2012 (UTC)
5. Equal preference with 6.2. I don't consider this the heart of the case but it is a significant factor in the problems leading up to the case. Newyorkbrad (talk) 03:52, 16 January 2012 (UTC)
6. equal with following. Casliber (talk · contribs) 07:30, 16 January 2012 (UTC)
7. First choice,  Roger Davies ^talk 10:17, 21 January 2012 (UTC)
8. First choice. Risker (talk) 20:29, 21 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Adapted from Senkaku islands. Some of the specific communications in question involve matters known to the committee but not in evidence. Jclemens (talk) 21:56, 14 January 2012 (UTC)

Suggested rephrasing: "Although Betacommand was counseled on communication issues during the prior cases, his manner and style of communications during disputes can still cause concern. Whether intentional or not, Betacommand's off-Wiki communications in the current matter have at times been unhelpful." SilkTork ^{✔Tea time} 13:18, 15 January 2012 (UTC)

I'd amend "has not improved" to "remains problematic." I don't think it's deliberate, but that doesn't stop it being a problem. Is there a principle to match against this - we had one at Senkaku. Elen of the Roads (talk) 13:25, 15 January 2012 (UTC)

Ongoing communication problems

6.2) Although Betacommand was counseled on communication issues during the prior cases, his manner and style of communications during disputes can still cause concern. Whether intentional or not, Betacommand's on and off-Wiki communications in the current matter have at times been unhelpful.

Support:

1. Rephrased. SilkTork ^{✔Tea time} 13:21, 15 January 2012 (UTC)
2. I can live with this one too. Jclemens (talk) 17:34, 15 January 2012 (UTC)
3. Second choice. PhilKnight (talk) 18:50, 15 January 2012 (UTC)
4. Equal preference with 6.1, in light of changed wording, which I believe alleviates Kirill's and Elen's concerns. Newyorkbrad (talk) 03:52, 16 January 2012 (UTC)
5. equal with preceding. Casliber (talk · contribs) 07:30, 16 January 2012 (UTC)
6. Second choice. Kirill ^{[talk] [prof]} 16:14, 17 January 2012 (UTC)
7. Second choice,  Roger Davies ^talk 10:17, 21 January 2012 (UTC)
8. Second choice. Risker (talk) 20:29, 21 January 2012 (UTC)

Oppose:

The problems are not limited to off-wiki communications. Kirill ^{[talk] [prof]} 14:15, 15 January 2012 (UTC)

Abstain:

Comments:

It's not just his offwiki comms that are a problem - to be honest it's every time he opens his mouth to say anything but suggestions for technical activity. Elen of the Roads (talk) 13:23, 15 January 2012 (UTC)

I've amended to "on and off-Wiki". I'm not comfortable with "has not improved" and "frustrated involved and uninvolved editors", which are not neutral terms. We can say the same things without such emotive energy. Also, I'm not comfortable with the off-stage addendum of "Some of the specific communications in question involve matters known to the committee but not in evidence." SilkTork ^{✔Tea time} 14:31, 15 January 2012 (UTC)

Template

7) {text of proposed finding of fact}

Support:

Oppose:

Abstain:

Comments:

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.

Community sanctions confirmed

1.1) The Arbitration Committee confirms that the imposition of sanctions on Betacommand by the editorial community was a legitimate exercise of the community's authority, and that it has found no grounds to overturn or reduce these sanctions.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. Eith Kirill's clarification. SirFozzie (talk) 02:17, 4 January 2012 (UTC)
3. Jclemens (talk) 03:32, 4 January 2012 (UTC)

Oppose:

1. AGK [•] 01:38, 4 January 2012 (UTC)
2. On reflection, I think just 1.5 is required. PhilKnight (talk) 15:45, 4 January 2012 (UTC)
3. In favor of 1.5. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
4. Oppose and supercede by new (simpler and delineated) remedy Casliber (talk · contribs) 11:13, 12 January 2012 (UTC)
5. Going with 1.5. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
6. The sanctions are not working. SilkTork ^{✔Tea time} 22:32, 12 January 2012 (UTC)
7. I hate to do this, but I'm proposing 1.7 instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
8.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Suggest splitting this into two. PhilKnight (talk) 00:05, 4 January 2012 (UTC)

Agree with first part of sentence. Would prefer that if the Committee is to ban Betacommand that we do so in a more affirmative manner rather than falling back on the community ban, so am uncomfortable with the second part. SilkTork ^{✔Tea time} 00:43, 4 January 2012 (UTC)

Again, this is a 180 from what the Committee apparently decided when they relaxed the ban. We are the final step of dispute resolution here, and undoing the previous action the Committee took seems to be the equivalent of dropping back 10 yards and punting. I'm willing to go either way, but I'd prefer to get something from us rather then going back to the Community Ban, because I KNOW that there will immediately be a AN/ANI dramafest as his supporters seek to lift the community ban and his detractors seek to enforce it. SirFozzie (talk) 01:10, 4 January 2012 (UTC)

To clarify, this is intended to reference the current sanctions, not the previous ban. Kirill ^{[talk] [prof]} 01:22, 4 January 2012 (UTC)

Thanks for that clarification. SilkTork ^{✔Tea time} 09:25, 5 January 2012 (UTC)

Community sanctions confirmed

1.2) The Arbitration Committee confirms that the imposition of the current set of sanctions on Betacommand by the editorial community was a legitimate exercise of the community's authority.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 01:22, 4 January 2012 (UTC)
2. Third choice to 1.5 and 1.4 Courcelles 03:18, 4 January 2012 (UTC)
3. Jclemens (talk) 03:34, 4 January 2012 (UTC)

Oppose:

1. Prefer 1.4. AGK [•] 01:38, 4 January 2012 (UTC)
2. On reflection, I think just 1.5 is required. PhilKnight (talk) 15:44, 4 January 2012 (UTC)
3. In favor of 1.5. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
4. As above. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
5. The sanctions are not working. SilkTork ^{✔Tea time} 22:32, 12 January 2012 (UTC)
6. I hate to do this, but I'm proposing 1.7. instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
7.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

No grounds to overturn community sanctions

1.3) The Arbitration Committee confirms that it has found no grounds to overturn or reduce the current set of sanctions imposed on Betacommand by the editorial community.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 01:22, 4 January 2012 (UTC)
2. AGK [•] 01:38, 4 January 2012 (UTC)
3. Jclemens (talk) 03:34, 4 January 2012 (UTC)
4. Courcelles 03:49, 4 January 2012 (UTC)

Oppose:

1. On reflection, I think just 1.5 is required. PhilKnight (talk) 15:44, 4 January 2012 (UTC)
2. In favor of 1.5. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
3. As above. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
4. The sanctions are not working. SilkTork ^{✔Tea time} 22:32, 12 January 2012 (UTC)
5. I hate to do this, but I'm proposing 1.7 instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
6.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Community sanctions confirmed

1.4) The Arbitration Committee confirms the current set of sanctions on Betacommand (which were imposed by the community).

Support:

Harvested Kirill's follow-up proposal. In my mind, 1.2) does not adequately convey that we are confirming the community sanctions in the sense that they become a Committee action and not open to reversal or drama-mongering at ANI or related noticeboards. We could go further and vacate the community sanctions, then pass sanctions taken verbatim from the current community ones, but that strikes me as needlessly convoluted; nevertheless, per SirFozzie in 1.1), I think we need to say not only that the community sanctions are reasonable but that they are given ArbCom confirmation. AGK [•] 01:38, 4 January 2012 (UTC) Moved to oppose.

1. Second choice; if Betacommand is banned, the precise character of these sanctions will be somewhat academic. Kirill ^{[talk] [prof]} 01:39, 4 January 2012 (UTC)

   They will be largely academic unless Betacommand has reformed enough to successfully appeal after one year, which I earnestly hope will be the case. AGK [•] 01:53, 4 January 2012 (UTC)

2. Prefer this. SirFozzie (talk) 02:18, 4 January 2012 (UTC)
3. Second choice to 1.5. Courcelles 03:54, 4 January 2012 (UTC)
4. Jclemens (talk) 03:35, 4 January 2012 (UTC)

Oppose:

1. On reflection, I think just 1.5 is required. PhilKnight (talk) 15:40, 4 January 2012 (UTC)
2. In favor of 1.5. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
3. Oppose and supercede by new (simpler and delineated) remedy. Casliber (talk · contribs) 11:12, 12 January 2012 (UTC)
4. Moved to oppose. My preference is for the new proposal of a BAG-only restriction, which means we are overturning the previous community sanctions. AGK [•] 11:23, 12 January 2012 (UTC)
5. As above. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
6. The sanctions are not working. SilkTork ^{✔Tea time} 22:32, 12 January 2012 (UTC)
7. I hate to do this, but I'm proposing 1.7 instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
8.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Community sanctions continued as arbitration remedies

1.5) The Arbitration Committee takes possession of the current set of sanctions on Betacommand (which were imposed by the community), and continues them as arbitration remedies.

Support:

1. Proposed as more explicit statement of what I think 1.4 is trying to say. (Confirms is a rather ambigious verb in this context as to what this remedy actually accomplishes. Feel free to copyedit.) Courcelles 03:54, 4 January 2012 (UTC)
2. Jclemens (talk) 06:21, 4 January 2012 (UTC)
3. Second choice, as with 1.4. Kirill ^{[talk] [prof]} 12:50, 4 January 2012 (UTC)

   PhilKnight (talk) 15:29, 4 January 2012 (UTC) Move to oppose. PhilKnight (talk) 17:10, 13 January 2012 (UTC)

4. A suggestion, perhaps, that a copyedit to "endorses and adopts" could be the best wording, but I think this is clear as written. — Coren ^(talk) 16:35, 4 January 2012 (UTC)
5. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)

Oppose:

1. The sanctions are not working. I'm not sure how it would be helpful for ArbCom to take responsibility for unworkable sanctions. SilkTork ^{✔Tea time} 09:31, 5 January 2012 (UTC)

   My read of the situation, after reading reams and reams of archives, is that the sanctions aren't working because of the bickering around them, and not because they are fundamentally flawed per se. Every time edits of Betacommand's end up being reviewed, there is a tug-of-war around interpretation that devolves into a "no consensus" dispute.

   Making those sanction arbitration remedies has three properties I believe will fix the problem: (a) discussion at AE is considerably more structured than some random subpage of ANI; (b) the people that keep the discussion stalling are involved, and AE process clearly removes them from the mess, and (c) enforcement of an arbitration remedy is considerably more stable (the process for appeal is well-delineated). — Coren ^(talk) 04:13, 6 January 2012 (UTC)

   That's a valid point. I'm not quite convinced that shifting the discussion venue will entirely prevent queries about Betacommand's editing, though I am prepared to consider the possibility. SilkTork ^{✔Tea time} 09:46, 6 January 2012 (UTC)

2. New simple conditions below make them moot.Casliber (talk · contribs) 11:11, 12 January 2012 (UTC)
3. My preference is for the BAG-only edits restriction, which means previous restrictions will have to be vacated. AGK [•] 11:23, 12 January 2012 (UTC)
4. I would not willingly put my name to that set of restrictions. Elen of the Roads (talk) 22:22, 12 January 2012 (UTC)
5. Similar to AGK, I've now supported Remedy 6, and so this isn't compatible. PhilKnight (talk) 17:10, 13 January 2012 (UTC)
6. I hate to do this, but I'm proposing 1.7 instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
7.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Community sanctions vacated

1.6) The current set of sanctions on Betacommand, which were imposed by the community, are vacated.

Support:

1. If Remedy 6 passes, I think this is needed to clarify the situation. PhilKnight (talk) 17:13, 13 January 2012 (UTC)

Oppose:

1. If we intend to vacate the sanctions outright, we need to outline a basis in policy for doing so. There is not, at the moment, any finding that the sanctions were in any way improper. Kirill ^{[talk] [prof]} 05:18, 15 January 2012 (UTC)
2. Wrong direction. If there was community consensus to undo the sanctions, this matter would not be before us now. Jclemens (talk) 17:35, 15 January 2012 (UTC)
3. I hate to do this, but I'm proposing 1.7 instead. Newyorkbrad (talk) 04:02, 16 January 2012 (UTC)
4.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Even though remedy 6 and the first thrree sanctions are incompatible, I see no grounds to vacate sanction 4... Courcelles 17:29, 15 January 2012 (UTC)

In my experience, civility parole is often problematic as the amount of community time and effort expended isn't offset by any discernible improvement. However, if you consider it's worthwhile, I suggest you propose an alternative, and I'll give a 'second choice support'. PhilKnight (talk) 18:39, 15 January 2012 (UTC)

@ Kirill, the community sanctions were properly imposed, but unsuccessful in resolving the problem, hence the need for this case. In my view, this allows us to replace the sanctions with Remedy 6. PhilKnight (talk) 18:33, 15 January 2012 (UTC)

@ Kirill. The policy basis is "To act as a final binding decision-maker primarily for serious conduct disputes the community has been unable to resolve". If that involves vacating sanctions which are not working, so be it.  Roger Davies ^talk 10:00, 16 January 2012 (UTC)

Community sanctions superseded

1.7) The Arbitration Committee determines that the existing community sanctions on Betacommand were a valid response by the community to prior problems with Betacommand's editing, and that Betacommand was required to abide by those sanctions if he wished to continue editing. However, given that interpretation and implementation of those sanctions has led to ongoing disputes, the community sanctions are superseded by the more straightforward remedies provided for in this decision.

Support:

1. Let's try this one. The community sanctions were validly imposed and were binding, and Betacommand should have made a more determined effort to abide by them. However, the complexity of the sanctions seems to have led to problems of its own, and the remedies contained in this decision, whatever they may be, will certainly result in a simpler regime. Therefore, I think this is the best wording. To the extent arbitrators believe one or more of the existing sanctions should remain in place, they can propose them as remedies and we can vote on them individually, in which context the usefulness and workability of each can be evaluated. Newyorkbrad (talk) 15:42, 16 January 2012 (UTC)
2. Hits nail on head. Casliber (talk · contribs) 07:31, 16 January 2012 (UTC)
3. Conditional to either 6 or 7 passing. Courcelles 07:44, 16 January 2012 (UTC)
4. PhilKnight (talk) 08:43, 16 January 2012 (UTC)
5. Yes, this works. SilkTork ^{✔Tea time} 09:26, 16 January 2012 (UTC)
6. Fair enough. Kirill ^{[talk] [prof]} 14:54, 16 January 2012 (UTC)
7. Okay,  Roger Davies ^talk 10:38, 21 January 2012 (UTC)
8. Okay. Only choice. Risker (talk) 20:31, 21 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Willing to support this when and if restrictions more stringent and/or clear are passing. This alone passing without improving the restrictions themselves is a de facto lifting of the restrictions without qualification, which I cannot support. Jclemens (talk) 04:18, 16 January 2012 (UTC)

I can certainly understand holding off on voting on this until we see what the rest of the decision will be. Newyorkbrad (talk) 04:41, 16 January 2012 (UTC)

Betacommand banned

2.1) Betacommand is banned from Wikipedia for a period of no less than one year.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. This is what I prefer. The community ban being lifted and a Committee ban being enacted, just to clear things up. SirFozzie (talk) 01:10, 4 January 2012 (UTC)

   • Inclined to support, but holding vote for now. With regret, I too would ban Betacommand: at this point, he has exhausted the patience of the community and became a serious drain on Wikipedia's resources. With the understanding that, until a satisfactory appeal is submitted, the ban is indefinite (as provided by R#3), I am not sure what a one-year ban would achieve. Betacommand cannot return to Wikipedia until he is capable of engaging in this project in a constructive, professional way, and a one-year ban does not achieve this. AGK [•] 01:49, 4 January 2012 (UTC) I prefer the BAG-only edits restriction. AGK [•] 11:23, 12 January 2012 (UTC)

   Second choice to remedy 4. Courcelles 03:11, 4 January 2012 (UTC)

3. First choice. Jclemens (talk) 03:13, 4 January 2012 (UTC)
4. The problem is that Betacommand needs to change his behaviour, not that he needs a fixed period away from Wikipedia. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
5. First choice. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
6.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Oppose:

1. Prefer 2.2 PhilKnight (talk) 00:12, 4 January 2012 (UTC)
2. I think we can work something out here, and a well-circumscribed and defined editing brief which he sticks to is possibly a net positive over a site ban. Casliber (talk · contribs) 19:53, 7 January 2012 (UTC)
3. Oppose for now, I think we can find something more optimal, even if this would be an improvement on the situation as it has been the last few months. Will re-evaluate if we can't come to consensus on something promising that is a lesser sanction. Courcelles 22:21, 7 January 2012 (UTC)
4. Prefer 6). AGK [•] 11:23, 12 January 2012 (UTC)
5. No point, per Coren above. Either we agree that we will create an editing space for him, or we ban him for good, and I'm not supporting the latter option. --Elen of the Roads (talk) 22:26, 12 January 2012 (UTC)
6. Prefer remedy 6 - restrict to bot use and management. SilkTork ^{✔Tea time} 12:11, 13 January 2012 (UTC)

Abstain:

Comments:

I'd like to consider other options before voting for or against a ban. The community were recently divided on lifting the restrictions. And is there clear evidence of significant errors in recent editing, or disruptive editing? SilkTork ^{✔Tea time} 02:45, 4 January 2012 (UTC)

My own thinking is that, considering the evidence and the contents of the ANI sub-board that is (as a dubious honour) dedicated to Betacommand's actions, all other options have been exhausted. Various formulations of mid-way sanctions on Betacommand's activities have failed, in no small part because Betacommand has subverted or disregarded them. I do not see what other option we have here. AGK [•] 02:52, 4 January 2012 (UTC)

Indeed; in a similar vein, one might consider that this case is Betacommand 3, not Betacommand 1. We've run out of options, and the community has run out of patience. Kirill ^{[talk] [prof]} 03:00, 4 January 2012 (UTC)

The option of a Clean start does not appear to have been explored. The options of an ArbCom notified Clean start account with a) no restrictions; b) restrictions on using a bot and a topic ban on non-free material; or c) same restrictions as currently in place, might be worth looking at. All with an annual report to ArbCom, and the possibility of returning to edit in his present account if his edits do not contain significant errors. What is clear from this case is that Betacommand's history is problematic, and that history has an impact on both Betacommand and the community's dealings with him. What is not clear is that his recent edits have in themselves contained significant errors. SilkTork ^{✔Tea time} 08:08, 4 January 2012 (UTC)

As has been pointed out elsewhere, a clean start account operated by Betacommand will almost certainly be identified within days, if not hours; his editing style is reasonably distinctive. Allowing a clean start would also run counter to the community's determination that it was the content of Betacommand's edits which was problematic, not merely the fact that it was Betacommand who made them. Kirill ^{[talk] [prof]} 12:52, 4 January 2012 (UTC)

I think it would be appropriate to give Betacommand the option of making legitimate edits away from potentially hostile glares. If Betacommand makes mistakes with the clean account, then we'll know it is Betacommand's fault not the community's. If someone identifies the account, and the account is making legitimate edits, they would have no more reason to criticise the account than any other. I take on board your last point that the community have historically been concerned at the quality of Betacommand's account; however, having reviewed the recent discussions presented as evidence, the community appear to be at a point of balance of opinion regarding lifting restrictions on Betacommand as it is felt that his recent edits have not been any more significantly error filled than any other editor's - any recent concerns have more to do with Betacommand's reactions to questions about his excessing the restrictions than about the quality of his edits. This case was brought because the community were discussing lifting some restrictions, and ArbCom was asked to reflect on that matter. Going from considering lifting editing restrictions to banning without offering a stage in between is perhaps too big a leap to take. My concern is that simply lifting restrictions would not work because of the drama attached to the account, but offering a clean start under ArbCom control seems a reasonable middle way to offer. I'd like us to have that option, and will look at some wordings. The Committee may vote against the option, though I think it is appropriate that we at least have it as an option. SilkTork ^{✔Tea time} 14:19, 4 January 2012 (UTC)

• (Cross-posted from talk) To me, the central problem is how Betacommand interacts with the community and our readership. Those interactions which are unsatisfactory are always related to those automated or scripted edits that have not been approved and tested in advance, for instance when he uses automated scripts (like Twinkle or AWB) for which there is no approval process. His bots - vetted by the community's Bot Approvals Group - run without controversy, and δbot has been running well for some time and without issue. I understand that other bot operators (like MZMcBride) have offered to take over the running of δbot, but I think that does a disservice to Beta - and to ban him because, ostensibly, his usefulness is in running bots and "anybody else can do that, so we don't need him" would be astonishingly callous. If there are feasible alternative remedies than to remove Betacommand from the site, we should hear them out.

  When we turn to the proposed decision and consider how to resolve the issue with Betacommand's approach to interaction, I rejected the one-year ban, because the problem is with Betacommand's interactions - which a one-year break from Wikipedia would not solve. An indefinite ban, with a return only upon the presentation of a satisfactory plan for contributing constructively, would be a solution in that it would ensure Betacommand could only return if he became capable of contributing without the generation of a plethora of heated discussion. However, if we could agree that Betacommand was only problematic inasmuch as he runs (and apparently messes up) unapproved cleanup-style runs (not vetted bots), then a sensible solution could be to ban him from making any edit that was not approved in advance by BAG. Of those remedies that would meaningfully resolve the "Betacommand problem", I am inclined to pass the least severe proposal; if we do so and the problem persists, a siteban could be instituted by motion with little difficulty (and a remedy resolving that we will siteban in the event of continued issues with Betacommand may need to be included). Apologies for the verbosity, but I wanted to set my views down clearly before we proceed. AGK [•] 15:16, 4 January 2012 (UTC)

Betacommand banned for 1 year

2.2) Betacommand is banned from Wikipedia for a period of one year.

Support:

1. PhilKnight (talk) 00:12, 4 January 2012 (UTC)
2. Second choice. SirFozzie (talk) 01:10, 4 January 2012 (UTC)
3. Second choice; given the number of times Betacommand has been sanctioned in the past, I have no confidence that the passage of a year will necessarily resolve the underlying problem. Kirill ^{[talk] [prof]} 01:17, 4 January 2012 (UTC)
4. Jclemens (talk) 03:13, 4 January 2012 (UTC)
5. Second choice. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)

Oppose:

1. A one-year ban would not achieve what is needed from Beta. AGK [•] 01:50, 4 January 2012 (UTC)
2. I don't think a time-limited ban will solve this problem, just kick it down the road. Courcelles 03:11, 4 January 2012 (UTC)
3. That'd just be pushing the problem forward one year, IMO. Reject in favor of 2.1. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
4. I think we can work something out here, and a well-circumscribed and defined editing brief which he sticks to is possibly a net positive over a site ban. Casliber (talk · contribs) 19:53, 7 January 2012 (UTC)
5. I hope something other than a ban can be worked out - if not, a rolling ban with appeal options is more responsive than a fixed term, so this wouldn't be my choice. SilkTork ^{✔Tea time} 22:55, 7 January 2012 (UTC)
6. Still no Elen of the Roads (talk) 22:26, 12 January 2012 (UTC)
7.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Appeal of ban

3) After one year has elapsed from the date of his ban, Betacommand may request that the ban be lifted. As part of any such request, Betacommand shall be required to submit a plan outlining his intended editing activity and demonstrating his understanding of and intention to refrain from the action which resulted in his ban. The Committee shall present this plan to the community for review and comment prior to any modification of Betacommand's ban.

Support:

1. Proposed. Kirill ^{[talk] [prof]} 23:23, 3 January 2012 (UTC)
2. Only if 2.1 passes. PhilKnight (talk) 00:13, 4 January 2012 (UTC)
3. If 2.1 Passes, and I'd prefer that it be to us, and we'd invite public comment, but that's just quibbling. (my thought is since it's the Committee that's banning him, the buck stops here, so to speak., SirFozzie (talk) 01:10, 4 January 2012 (UTC)
4. Only if 2.1 passes. AGK [•] 01:50, 4 January 2012 (UTC)
5. Iff 2.1 passes. Jclemens (talk) 03:14, 4 January 2012 (UTC)
6. If 2.1 passes Courcelles 03:16, 4 January 2012 (UTC)
7. Iff 2.1 passes. — Coren ^(talk) 16:43, 4 January 2012 (UTC)
8. Iff 2.1 passes. Casliber (talk · contribs) 19:53, 7 January 2012 (UTC)
9. If 2.1 passes. (Or 6) SilkTork ^{✔Tea time} 22:57, 7 January 2012 (UTC)
10. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
11.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Oppose:

Abstain:

Comments:

This could be tweaked to include 6 (Betacommand limited to BAG approved tasks). SilkTork ^{✔Tea time} 23:01, 7 January 2012 (UTC)

Betacommand restricted

4) Betacommand is indefinitely prohibited from using any automation whatsoever on Wikipedia. He may not make any edits that effect the same change, broadly construed, to any more than five pages in a 24-hour period. Should he be questioned on any edit he has made, he is expected to immediately stop the edits, and engage in a discussion with the user questioning his edits. These restrictions modify the community sanctions, and they remain in effect in other respects.

Support:

1. As an alternative to the full site-ban. Should this pass, attempting to nibble at the boundaries of the restrictions would not be looked upon favourably. Courcelles 03:06, 4 January 2012 (UTC)
2. As an additional sanction. That is, my preference is that he both be banned and, in the event that a ban is ever overturned, be restricted per this remedy. Jclemens (talk) 03:30, 4 January 2012 (UTC)

Oppose:

1. This will just lead to more endless arguments about what "same change" means, and whether editing a 6th page 23 hours and 59 minutes after the 1st needs to result in a block. Kirill ^{[talk] [prof]} 03:21, 4 January 2012 (UTC)
2. If we're going to go this far, we're already in tune with a ban. SirFozzie (talk) 04:15, 4 January 2012 (UTC)
3. I think that the currently endorsed sanction will do the job (including after a return from a ban, if that passes). — Coren ^(talk) 16:37, 4 January 2012 (UTC)
4. PhilKnight (talk) 18:05, 4 January 2012 (UTC)
5. I like having an alternative to banning, but I think this would create drama. Also, as there is evidence that Betacommand's current bot is useful and trouble free, it would need to be tweaked to allow User:Δbot to continue. SilkTork ^{✔Tea time} 19:28, 4 January 2012 (UTC)
6. pretty much as SirFozzie and Kirill. Casliber (talk · contribs) 12:15, 6 January 2012 (UTC)
7. Prefer 6). AGK [•] 11:23, 12 January 2012 (UTC)
8. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
9. God no. (a) the arguments would be horrendous - short of having Maxwell's Demon sitting on his shoulder, how would you tell since he uses unidentified tools (b) I honestly think that Beta is physically/mentaly/emotionally/intellectually/technologically/spiritually/or something/ unable to make single edits a lot of the time. I don't want to speculate on why, as I have no evidence. Elen of the Roads (talk) 22:30, 12 January 2012 (UTC)
10.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

• Holding my vote for now, but Courcelles, this is irreconcilable with much of the other proposals. The theme of this draft is that the community sanctions (listed at Betacommand 2) are sound and do not need amendment by this committee; as a sub-issue, the failure of the community sanctions is due to subversion of their terms by Betacommand himself. This proposal would supersede the community-imposed restrictions, and I'm not sure at this point whether we should be replacing the current sanctions with one of harsher terms, or banning Beta outright. I'll need to think more on this proposal, but my inclination for now is that this would do nothing that we as a community have been trying to achieve for several years... AGK [•] 03:23, 4 January 2012 (UTC)

• I'm open to other ideas, but this is what I came up with. Notice I did support a site ban, but I feel we do this case a disservice if there isn't something else on the table to consider other than a site ban. I can't shake this feeling that there is another solution out there... and a hard, firm restriction without reason for game-ability is one option. Courcelles 03:28, 4 January 2012 (UTC)

• Fair enough. I don't disagree, and I simply wanted to point out that some of the rest of the decision will have to be rewritten if we choose to solve this dispute in this way. I'm inclined to explore a mid-way option between siteban and the current community sanctions (which are lenient compared to even this proposal). Xeno has proposed something that might work better than this, on the talk page, but I agree on principle that we need to explore something like this. AGK [•] 15:19, 4 January 2012 (UTC)

Betacommand offered a clean start

Betacommand offered a clean start with no restrictions

5.1) Betacommand is offered a clean start with no restrictions on editing. The account to be revealed to ArbCom, and Betacommand to provide to ArbCom an annual report on editing activity.

Support:

Oppose:

1. This would be too big a step - there remain some concerns in the community about some aspects of Betacommand's editing. SilkTork ^{✔Tea time} 19:20, 4 January 2012 (UTC)
2. No. This isn't a clean start at all. Courcelles 19:32, 4 January 2012 (UTC)
3. Given the amount of effort spent in rehabilitating Betacommand, a "clean start" is an odd next step. It implicitly presumes that the problem is not with Betacommand himself, but with users who are harassing him. Jclemens (talk) 01:29, 5 January 2012 (UTC)
4. Agree with Jclemens - this presumes the main problem is with users harassing Betacommand, instead of with his editing. While there have been some problems with other users assuming bad faith and so on, I consider the main problem to be his editing pattern. PhilKnight (talk) 01:48, 5 January 2012 (UTC)
5. Kirill ^{[talk] [prof]} 03:56, 5 January 2012 (UTC)
6. I don't think there is any dispute that some other editors have behaved poorly when interacting with Betacommand. Nevertheless, what misbehaviour may have taken place is clearly not the source of Betacommand's repeated run-ins with the community, nor is it likely that his problems would be solved merely by obfuscating his identity. Indeed, I'd wager the opposite holds true: if some unknown editor had interacted this badly around numerous automated processes, they would have been shown the door long ago.

   That said, even if we granted that Betacommand's difficulty stemmed mostly (or even just in significant part) from people focusing on him specifically, it's not clear that this would be an allowable change of identity (given that it condones avoiding scrutiny) or that such a change would have any plausible chance of success. — Coren ^(talk) 04:41, 5 January 2012 (UTC)

7. does nothing to address the editing problems. Casliber (talk · contribs) 09:12, 6 January 2012 (UTC)
8. I do not think a clean start would be successful, nor do I think it would resolve this dispute. I prefer 6). AGK [•] 11:23, 12 January 2012 (UTC)
9. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
10. He is being harassed - and I believe we should have FoF'd that, but you'd spot him within 10 minutes. Elen of the Roads (talk) 22:32, 12 January 2012 (UTC)
11. Per most above. Newyorkbrad (talk) 04:04, 16 January 2012 (UTC)
12.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Betacommand offered a clean start with full restrictions

5.2) Betacommand offered a clean start with the current community and ArbCom restrictions in place. The account to be revealed to ArbCom, and Betacommand to provide to ArbCom an annual report on editing activity.

Support:

Oppose:

1. The restrictions would need more monitoring than ArbCom could reasonably provide, and the community has already shown there is a balance of opinion regarding relaxing the restrictions. SilkTork ^{✔Tea time} 19:20, 4 January 2012 (UTC)
2. Lots of work, solves nothing. Courcelles 19:32, 4 January 2012 (UTC)
3. Per my reaction to 5.1. Jclemens (talk) 01:29, 5 January 2012 (UTC)
4. Kirill ^{[talk] [prof]} 03:56, 5 January 2012 (UTC)
5. Per 5.1. — Coren ^(talk) 04:41, 5 January 2012 (UTC)
6. would not be a clean start and identified pretty quickly. Casliber (talk · contribs) 09:13, 6 January 2012 (UTC)
7. I do not think a clean start would be successful, nor do I think it would resolve this dispute. I prefer 6). AGK [•] 11:23, 12 January 2012 (UTC)
8. PhilKnight (talk) 12:34, 12 January 2012 (UTC)
9. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
10. Per most above. Newyorkbrad (talk) 04:04, 16 January 2012 (UTC)
11.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Betacommand offered a clean start with some restrictions

5.3) Betacommand offered a clean start with current restrictions lifted apart from the motion which topic bans Betacommand from Wikipedia:Non-free content criteria and reminds Betacommand of civility restrictions. Betacommand is to use only one approved bot, and keep it within approved parameters. The account to be revealed to ArbCom, and Betacommand to provide to ArbCom an annual report on editing activity.

Support:

1. This keeps some control, though allows enough freedom to see if Betacommand can edit appropriately. SilkTork ^{✔Tea time} 19:20, 4 January 2012 (UTC)

Oppose:

1. A clean start under sanctions defies the basic idea of clean start, and in general this sets a terrible precedent of letting community sanctioned users start new accounts. Betacommand has been unable to abide fully with his restrictions with them in full light of day, placing the monitoring of them on the 15 of us who would be the only ones who knoew of the account is a bad idea. Courcelles 19:41, 4 January 2012 (UTC)
2. Per my reaction to 5.1. Jclemens (talk) 01:30, 5 January 2012 (UTC)
3. Kirill ^{[talk] [prof]} 03:56, 5 January 2012 (UTC)
4. Per 5.1. In addition, the Committee does not have the resources to monitor "secret parolees". — Coren ^(talk) 04:41, 5 January 2012 (UTC)
5. as per 5.2. Casliber (talk · contribs) 09:14, 6 January 2012 (UTC)
6. I do not think a clean start would be successful, nor do I think it would resolve this dispute. I prefer 6). AGK [•] 11:23, 12 January 2012 (UTC)
7. PhilKnight (talk) 12:35, 12 January 2012 (UTC)
8. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
9. Abuse of cleanstart --Elen of the Roads (talk) 22:34, 12 January 2012 (UTC)
10. Per most above. Newyorkbrad (talk) 04:04, 16 January 2012 (UTC)
11.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Some tweaks needed, though the basic option is there for consideration. SilkTork ^{✔Tea time} 19:20, 4 January 2012 (UTC)

Betacommand limited to BAG approved tasks

6) Betacommand is indefinitely prohibited from editing Wikipedia article pages except from an approved bot account to carry out clearly delineated tasks specifically authorized by the Wikipedia:Bot Approvals Group. Except for his userspace (including usertalk space), his main account may only edit on talk pages or noticeboards and only to respond to queries about his approved bot operations, or to make edits necessary to file and participate in his own Bot Request for Approvals.

Support:

1. Proposed from this page's talk page as another alternative. Please feel free to copyedit, especially those on the Committee more familiar with bot operations than I. Courcelles 18:21, 7 January 2012 (UTC)

   Distant choice. Support only if none of the site bans pass. Jclemens (talk) 19:06, 7 January 2012 (UTC)

2. Okay, presuming the choice is between this and a ban, and that the bot, if approved (so presumably a few folks have looked at it, are aware of it, and can revert changes) can run at whatever speed necessary, then this seems to square with what Betacommand does well. It seems prety clear and by its parameters supercedes the comple set of old motions and hopefully gives Beta clear guidelines and space to do what he enjoys. Casliber (talk · contribs) 11:08, 12 January 2012 (UTC)
3. First choice and only support. I think this is the best way to resolve the issues with Betacommand. AGK [•] 11:23, 12 January 2012 (UTC)
4. First choice. PhilKnight (talk) 12:44, 12 January 2012 (UTC)
5. If not banned, this seems like a decent remedy. Der Wohltemperierte Fuchs^(talk) 17:57, 12 January 2012 (UTC)
6. First choice (only choice). I think he will need close monitoring, and wouldn't expect BAG to manage anything except the bot approval process. But it will allow him to do database queries and build bots to tackle problems, stuff he's good at, and it will impose UAT, because he does have a high error rate to start with on any project (I guess most bot developers do).Elen of the Roads (talk) 22:40, 12 January 2012 (UTC)
7. I think this is worth trying, and is preferable to a ban. BAG - I assume - would be assessing Betacommand's bots in the same way they assess the bots of other users, so I'm not sure this would be an added burden, though it would be appropriate for BAG to be informed if this is implemented. SilkTork ^{✔Tea time} 12:09, 13 January 2012 (UTC)

Oppose:

1. I don't think it's reasonable to expect that BAG will be able or willing to act as a hands-on enforcer of arbitration remedies—recall the failure of our previous attempt to do this ([4])—and, given Betacommand's history of skirting the edges of restrictions, I don't see this as being workable without close, continuous monitoring. Kirill ^{[talk] [prof]} 13:24, 12 January 2012 (UTC)
2. Per Kirill. Jclemens (talk) 15:02, 12 January 2012 (UTC)
3. Per Kirill SirFozzie (talk) 02:45, 13 January 2012 (UTC)

   Per SilkTork and further to my own comments elsewhere, I don't think there is any question that Betacommand would become a burden on BAG. AGK [•] 15:03, 16 January 2012 (UTC)

   That's only because BAG doesn't intend to police his edits. I'm sure that BAG is more than capable of approving bot requests; what concerns me is who will be responsible for going through the hundreds or thousands of edits made by the bot to ensure that all of them have been approved. Recall that one of the main complaints about Betacommand's editing is his use of uninformative edit summaries; there's no easy way to determine what his bot will be doing without going through all the edits by hand. Kirill ^{[talk] [prof]} 17:49, 16 January 2012 (UTC)

4. Per Kirill. I could support this if it were backed by teeth; and if BAG weren't being expect to enforce AE remedies; and there were provisions for discussion/resolution of stuff like this.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

I'm aware that this and remedy four can not pass together. Not that that got much support anyhow... Courcelles 18:35, 7 January 2012 (UTC)

Needs to be reworded, I guess you mean restricted from editing in "wikipedia mainspace" or wikipedia article space", and able to post on noticeboards, article talk and user talk. Casliber (talk · contribs) 11:01, 12 January 2012 (UTC)

I'm inclined to this, though would like clarity on how many bots Betacommand would be allowed to run. The wording is not clear - it could be one or it could be unlimited. Rather than having issues about this later down the line, let us spell it out. And let's think about other details. Would current restrictions, sanctions, topic-bans applying to Betacommand also apply to the bot(s)? For example, would we allow a bot to work on non-free content criteria? SilkTork ^{✔Tea time} 13:33, 12 January 2012 (UTC)

But surely a bot can only run after it has been assessed by others and greenlit, so if someone were to nominate a few, then the approval rate would be limited by the reviewer, not the nominator (???) Casliber (talk · contribs) 20:13, 12 January 2012 (UTC)

So the remedy is not limiting the number of bots? And that is what everyone is voting on? And we can set up a separate remedy regarding sanctions and topic bans as they apply to the bot? SilkTork ^{✔Tea time} 22:25, 12 January 2012 (UTC)

If he wants to go back to working in NFCC, he could only do so on a task that could be done by a bot, with approval and full testing. And a big disclaimer that says "I'm just a bot. If you disagree, the discussion is at ..." Which should limit him quite a bit. Elen of the Roads (talk) 22:46, 12 January 2012 (UTC)

Thanks. I am seeing now that BAG would handle my concerns as part of the normal assessment process. SilkTork ^{✔Tea time} 12:09, 13 January 2012 (UTC)

Betacommmand restricted

7) Betacommand is prohibited from using any form of automated, semi-automated, or repetitive editing on Wikipedia, including bots, scripts, or repetition of any type of edit more than five times per calendar day, where the effect of the edits is to directly change multiple pages on Wikipedia in the same or a similar fashion.

Betacommand is permitted to use automated tools such as bots and scripts to prepare lists of pages that he believes would benefit from a particular type of edit. The output from the bot or script should be posted on a page within Betacommand's userspace, in a form understandable to other editors. Any other editor may review the list and, upon verifying that the proposed edits are useful, consistent with policy, and will not impair the content or appearance of the pages in question, that editor may implement the proposed edits, using a bot or script of his or her own if desired. Both Betacommand and the subsequent user will share editorial responsibility for the edits made in this fashion.

The bot approvals group may be asked to opine on the usefulness of any bot task that Betacommand proposes. In addition, as an alternative, Betacommand may propose to the bot approvals group that a bot be created or tasked to perform any automated editing task. If the bot or task is approved, an editor or editors other than Betacommand shall be designated to supervise and operate the bot.

Betacommand is advised that any pattern of failing to abide by the restrictions in this decision is likely to lead to a ban from the project without further warnings.

An appeal for modification of these restrictions may be made after at least one year from the date of this decision.

Support:

1. It's taken me too long (although I've toyed with this idea on the mailing list for a few days), but perhaps this cuts the Gordian knot. Betacommand's talent appears to be identifying tasks that could use automated editing and working out the type of program that will carry out the task. Betacommand's weak point appears to be actually implementing the automated editing program in a way that addresses whatever issue he's trying to fix without creating new problems. This approach would ensure the involvement of another user in making sure that we get the upside without the downside. Of course, this plan requires that there be other users willing to work alongside Betacommand in carrying out his proposed tasks, but I gather that there is a group of users who believe Betacommand adds great value to Wikipedia, and if that is the case I am confident they will assist. Copyedits welcome. Newyorkbrad (talk) 04:21, 16 January 2012 (UTC)
2. Amenable to this. Similar to remedy 6 but has been expanded upon. Casliber (talk · contribs) 07:33, 16 January 2012 (UTC)
3. Can live with this. Courcelles 07:43, 16 January 2012 (UTC)
4. Second choice. PhilKnight (talk) 08:45, 16 January 2012 (UTC)
5. Another option if 6 does not pass. Der Wohltemperierte Fuchs^(talk) 21:30, 17 January 2012 (UTC)

Oppose:

1. I still have some concerns about remedy 6, however I feel it is less problematic and less likely to generate inappropriate interactions than restrictions not far removed from those which have not worked. These restrictions allow for the sorts of interpretation which lead to disputes - "was that edit 'in a similar fashion' to the one done earlier today?" SilkTork ^{✔Tea time} 09:43, 16 January 2012 (UTC)
2. I see too much scope for wikilawyering with this proposal, and I don't think it goes far enough to solving the serious problem with Betacommand's conduct. I prefer 6). AGK [•] 14:54, 16 January 2012 (UTC)
3. As with #4 above, this will simply lead to endless arguments at the enforcement stage. Kirill ^{[talk] [prof]} 14:57, 16 January 2012 (UTC)
4. Per Kirill,  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments:

Except that "likely to lead to a ban" bit. If there's anything that would actually prompt the committee to ban Betacommand, I'm not entirely sure what it is. He's been doing the same sorts of fumbling around for years, and yet this is the proposal that's likely to actually be implemented. This is a very "stop, or I'll say 'stop' again!" message. Jclemens (talk) 08:32, 16 January 2012 (UTC)

My reading of the situation is that subtle restrictions on Betacommand have led to wasted hours of community discussion, and invited poor interactions between Betacommand and the community. A workable solution would need to avoid subtle restrictions. At the two extremes we have a complete ban and a complete lifting of the restrictions. Lifting of restrictions is highly likely not to work, as it is felt the community would still critically examine Betacommand's edits and this would lead to disputes. Leaving the restrictions in place is not appropriate as they are not working, and the community is exhausted dealing with the disputes. Having a solution which reshuffles the restrictions is likely to simply continue the disputes. Remedy 6 is effectively a site-ban, though allowing Betacommand to work in an area which fits his acknowledged skill set. The possibility of problematic community interaction is reduced. If there is a concern with edits, it would be a bot that would be stopped, not a human account, and that is less of a flash point. A grey area with remedy 6 is that it may drag BAG into disputes about Betacommand, and it may be helpful to look at possible scenarios to see if that could be prevented. If we end up deadlocked between a ban and remedy 6, I would be more prepared to move to a ban than to vote on continuing restrictions. SilkTork ^{✔Tea time} 10:09, 16 January 2012 (UTC)

Betacommand username reinstatement

8) Betacommmand must edit only from User:Betacommand and via whatever automated processes are currently approved. Any other accounts used are to be linked appropriately to User:Betacommand.

Support:

1. Jclemens (talk) 17:23, 16 January 2012 (UTC)

Oppose:

1. Don't consider this to be necessary. PhilKnight (talk) 11:03, 17 January 2012 (UTC)
2. No real value to forcing a change at this late stage; inability to type the name aside, everyone who needs to know already knows. Kirill ^{[talk] [prof]} 16:17, 17 January 2012 (UTC)
3. What's done is done, and Betacommand's new name wouldn't be an issue if the other issues were dealt with. Der Wohltemperierte Fuchs^(talk) 21:32, 17 January 2012 (UTC)
4. Likely shouldn't have been done without ArbCom approval as he was under sanctions, but since it is done and has been for a while, no reason to force a reversal now. Courcelles 02:21, 18 January 2012 (UTC)
5. Why? --Elen of the Roads (talk) 16:28, 20 January 2012 (UTC)
6. Per Der Fuchs.  Roger Davies ^talk 10:38, 21 January 2012 (UTC)

Abstain:

Comments

The Δ thing was never appropriate for a sanctioned user, and the fact that there's a whole template dedicated to referring to this user demonstrates that the name change is per se disruptive in effect, whatever the original motivation may have been. Jclemens (talk) 17:23, 16 January 2012 (UTC)

Does this actually solve any current problems, or just a procedural fix from the rename, which is comfortably far in the past I think everyone interested knows about it. Courcelles 18:40, 16 January 2012 (UTC)

The lack of continuity, even though not particularly secret, has been pointed out as an issue, and I agree that it is not appropriate for a sanctioned user to change names. So, in addition to him not having the same username under which he was first sanctioned, the other current problem is the difficulty of referencing "Delta", which, assuming we're not simply going to ban him, needs to be remedied for future discussions--involving those who know about {{DELTA}} as well as those who don't. Needing a learning curve to complain about a user who has prompted many complaints in the past is not appropriate. Jclemens (talk) 07:14, 17 January 2012 (UTC)

I can understand why (ex-)Betacommand wanted to try starting with a new username, even though a "clean start" was obviously not possible, so I don't think we necessarily want to force him to go back to being "Betacommand." On the other hand, a username like the one he is currently using is a pain in the neck for everyone, quite honestly, as reflected in our choice for the name of this case. As a compromise, how about a request that he edit under an account spellable in ordinary English letters (perhaps "Delta" or some variant, although I know at least one user who sometimes calls him "Triangle"). Newyorkbrad (talk) 22:18, 16 January 2012 (UTC)

As pointed out on the talk page, policy does not prohibit non-latin character usernames. So...ermm..that's that really, unless someone initiates a community discussion on this. Similarly we've had users abandon old accounts and restart. Casliber (talk · contribs) 08:23, 17 January 2012 (UTC)

Policy doesn't initially prevent a lot of things that we take away from users who've demonstrated repeated inability to handle themselves well. Allowing the rename in the first place was a mistake; this remedy just fixes that. Jclemens (talk) 09:25, 17 January 2012 (UTC)

Proposed enforcement

Enforcement by block

1) Should any user subject to a restriction in this case violate that restriction or ban, that user may be blocked, initially for up to one month, and then with blocks increasing in duration to a maximum of one year. Appeals of blocks may be made to the imposing administrator, and thereafter to Arbitration Enforcement, or to the Arbitration Committee.

Support:

1. Only if needed. PhilKnight (talk) 12:46, 12 January 2012 (UTC)
2. If something it would apply to passes, now including most of the subheaders of remedy 5. Courcelles 19:36, 4 January 2012 (UTC)
3. If anything relevant passes, sure. Jclemens (talk) 01:30, 5 January 2012 (UTC)
4. This should really be a part of some standard enforcement procedure rather than being individually adopted in each case. Kirill ^{[talk] [prof]} 03:57, 5 January 2012 (UTC)
5. True that (viz Kirill's comment). It seems a little silly to have an enforcement section that almost always contains exactly one provision that remains substantially the same (and which, in most cases, is not really necessary). Nevertheless, given we don't currently have a "default enforcement" procedure, we still need it. — Coren ^(talk) 04:30, 5 January 2012 (UTC)
6. If we pass 6) or another remedy requiring this standard enforcement provision. AGK [•] 11:32, 12 January 2012 (UTC)
7. If necessary. Der Wohltemperierte Fuchs^(talk) 18:03, 12 January 2012 (UTC)
8. To enforce remedy 6. SilkTork ^{✔Tea time} 18:46, 13 January 2012 (UTC)
9. Hopefully this won't come into play, but this sort of provision is a standard part of any decision. Newyorkbrad (talk) 04:44, 16 January 2012 (UTC)

Oppose:

Abstain:

Comments:

Following comments on the talk page, I've removed the mention of WP:ANI. PhilKnight (talk) 17:34, 13 January 2012 (UTC)

Discussion by Arbitrators

General

• As things stand, our Proposed_findings_of_fact section as it stands lacks an immediate antecedent to this case (i.e. the building block clarifying why this came about) Casliber (talk · contribs) 12:13, 6 January 2012 (UTC)

• I think that Finding 1) is sufficient as background, though it perhaps could be expanded (as a FoF 1.1)) to include remarks about the previous cases, and a greater emphasis on the community's history with trying to deal with Betacommand. AGK [•] 11:33, 12 January 2012 (UTC)

Motion to close

Implementation notes

Clerks and Arbitrators should use this section to clarify their understanding of the final decision--at a minimum, a list of items that have passed. Additionally, a list of which remedies are conditional on others (for instance a ban that should only be implemented if a mentorship should fail), and so on. Arbitrators should not pass the motion until they are satisfied with the implementation notes.

Proposals which pass

Principles: 2, 3, 4

Findings of fact: 1, 2.2, 4

Remedies: n/a

Enforcement provisions: n/a

Proposals which do not pass

Principles: 1

Findings of fact: 2.1, 3, 5, 6.1, 6.2

Remedies: 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 2.1, 2.2, 3 (dependent on 2.1 passing), 4, 5.1, 5.2, 5.3, 6, 7, 8

Enforcement provisions: 1 (dependent on certain remedies passing)

Last calculated by Alexandr Dmitri (talk) 18:31, 16 January 2012 (UTC)

Vote

Important: Please ask the case clerk to author the implementation notes before initiating a motion to close, so that the final decision is clear.

Four net "support" votes needed to close case (each "oppose" vote subtracts a "support"). 24 hours from the first motion is normally the fastest a case will close. The Clerks will close the case either immediately, or 24 hours after the fourth net support vote has been cast, depending on whether the arbitrators have voted unanimously on the entirety of the case's proposed decision or not.

Support

1. I'm done now. Casliber (talk · contribs) 11:20, 12 January 2012 (UTC) sigh. Need to figure this out...Casliber (talk · contribs) 20:27, 23 January 2012 (UTC)

Oppose

1. We've been voting for too long, but a lot of new ideas have came about since the draft PD was posted, and I would prefer that more of my colleagues vote on them before we look to close this case. Ideally, they would do so soon, because we're already very tardy with this case's delivery (for which I suspect the ArbCom Elections and the holiday season generally are to blame). Oppose closure until more votes come in. AGK [•] 11:35, 12 January 2012 (UTC)
2. I don't see a viable solution on which to vote - there are details which need exploring, and there is information missing from the decision page - such as that Betacommand has done positive work with reports and tools, and that the community are undecided on lifting sanctions. SilkTork ^{✔Tea time} 13:51, 12 January 2012 (UTC)
3. The fact that this was moved to voting prematurely does not create an obligation on us to leave the issue unresolved. Jclemens (talk) 15:01, 12 January 2012 (UTC)
4. This is nowhere near finished. Courcelles 21:51, 12 January 2012 (UTC)

Comments