Wikipedia talk:Dealing with disruptive or antisocial editors/poll/archive1

I'm not sure we should have two yes options (yes and yes but only for a trial period) I predict that most people will be cautious and vote for the trial period. We could just put it's a trial period in the intro straight off and keep the voting options simple. Also two months isn't very long. Disruptive editing can be complex - well more complex than straight vandalism anyway. I don't think two months is really long enough to evaluate how well the policy is working. I suggest doubling it to four months. Any thoughts? theresa knott 19:27, 21 Jul 2004 (UTC)

I do not think the right solution to this was to add yet another option. Option glut is bad - it makes it increasingly difficult to decide whether you have a real consensus for anything. If two months turns out to not be enough, we can extend it another two when the time comes. But let's not make this poll overwhelming. Snowspinner 23:51, Jul 25, 2004 (UTC)

I agree. My suggestion was to get rid of the "yes" and "yes but" options and merge them into a new "yes but we'll review in 4 months" That way there would have been two option yes and no, but now there are four. Oh well it's too late now.No one has voted for the four month option though. We could just remove it? theresa knott 00:00, 26 Jul 2004 (UTC)

We shouldn't be adding options after the poll has started. This was one of the best run polls I've ever seen up until that point. The list of options has been available for ten days now, before the poll started was the time to modify them. Since no one has voted on the option and I don't see any objections I'm going to remove it. anthony (see warning) 01:35, 26 Jul 2004 (UTC)

This is not complicated!

Come on people. I urge those who voted against to reconsider.

For the average user, this policy simply involves asking people nicely to stop doing whatever it is. Being able to speak softly while holding a big stick is going lower the temperature around here a lot. Most of the time we wont even get to step 1.

But, which bit exactly do people suggest we drop?

1. see a problem user
2. give the user a friendly warning
3. if the problem doesn't stop ….
   1. give the user another warning and point them to the right policy
   2. put a notice on Wikipedia:direction just like the ones already there
   3. gather a bit of evidence so you can explain to the community why this user may need to be blocked
4. if the problem doesn’t stop
   1. give them a stern warning and tell them they’ll be blocked
   2. gather a bit more evidence so you can explain to the community why this user must be blocked
5. if the problem doesn’t stop
   1. a couple of others will back you up
   2. block ‘em

If the user reoffends, don't cut them as much slack and block them for longer.

If there is controversy over the presented evidence then some voting will be needed.

best wishes Erich 20:42, 26 Jul 2004 (UTC)

If I wanted to simplify this I'd drop 2, 3.2, 4, the thresholds (other than that multiple warnings do not need to be made for the same behavior), the increasing block lengths, the section on reincarnations, the good behavior clause, and the voting, for starters. I'd simplify the definition to violating any policy. anthony (see warning) 21:12, 26 Jul 2004 (UTC)

so you'd say we only give people one warninging then we block them? (forgot to sign Erich 20:42, 28 Jul 2004 (UTC))

I certainly don't see the point of giving ten warnings (or even two). If someone is knowingly breaking policy I don't see the harm in a 24-hour block. If they weren't actually breaking policy, then this can be brought up through discussion, mediation, or arbitration, if another admin doesn't unblock them right away. anthony (see warning) 23:10, 28 Jul 2004 (UTC)

ahh.... well I agree with 2 warnings being enough... It is important the first warning is friendly and non threatening... otherwise we're biting newbies and just being a bit unpleasant really. I think a second stirn warning should be enough (I started with 2 from memory and the requirement for others was added by an unamed arbitrator)... so I definetly concede we could do with less warnings.... Erich 20:40, 29 Jul 2004 (UTC)

I don't think admins should ever be warning people in a non-friendly or threatening way. anthony (see warning) 20:44, 29 Jul 2004 (UTC)

Well, it says on the page: "This is a relatively complex proposal for a difficult problem." Could the summary from the policy be added to the poll page? Jrincayc 13:12, 28 Jul 2004 (UTC)

yeah it does its complicated doesn't it... I'm working all weeks (12 hour shifts) so no time to write a user guide... monday I've got a week off so will write a user guide then.

I am disapointed though :-(

its not a complicated policy to follow though. (warn-> gather evidence -> warn -> gather evidence -> warn -> gather evidence -> all agree -> block )

The devil is always in the detail so I put in a lot of detail to banish the devil. If the small points aren't covered people will have to argue them out later.

and its true that short policies are best... but where is the short policy that can put this issue to bed? there isn't one because its not possible... we can kid ourselves that it is and keep look but let me clue in ... it not possibe (compare this policy with the average piece of legislation ... it is very short in comparision). most of the detail in this policy is to prevent later arguement ... well another round of refinement may be in order... ;-) best wishes Erich 20:42, 28 Jul 2004 (UTC)

There's no short policy that will solve the problem. There's no long policy that will solve the problem. There isn't even an agreement on what the problem is. anthony (see warning) 23:13, 28 Jul 2004 (UTC)

so we give up? Erich 20:40, 29 Jul 2004 (UTC)

No, so we define the problem, get consensus that it's a problem, and then address it in the simplest way possible. We don't make the problem worse by adding layer upon layer of buerocracy. anthony (see warning) 20:44, 29 Jul 2004 (UTC)

Anthony, we had over two weeks working on the definition of the problem. and the troll polls did conclude that we have a problem and "something" needed to be done. I've been wrestling we with peoples concerns about the complexity and this is where I've got to: This is a simple policy to operate. Making it simpler would make it actually more complex. There are plenty of examples of systems that get easier to use as they get more complex. eg

• automatic versus manual gear boxes
• windows based operating systems versus command line interpreters

What do most Wikipedians need to know about this policy? Not much:

• If somebody is doing something disruptive or antisocial then ask them to stop. If they do not stop gather up the URLs to the diffs to the problem and provide the list to a friendly administrator, or add the list yourself to the direction page.

If you are an administrator:

• If a user approaches you about a difficult user then ask them to show you some diffs. If the complaint is reasonable then ensure somebody has given the difficult user a friendly warning and pointed them to the policy. Consider listing the user and the diffs on the dirctection page.
• Periodically have a look at the diffs on the directions page.
• Vote to support a formal warning if a first time offender the user has made 8 disruptive edits. If they have made two or more disruptive or antisocial edits after the formal warning vote to support the block. (You made need to check the definition in the policy)
• Repeat offenders and sock puppets get less leaway. Check the policy.
• There will be enough people lurking who understand the policy to correct any misinterpretations as they arise, and of course the AC may always intervene.

I really think Wikipedia can and should make this work. It's fair and transparent and is really worth the effort. Leaving things to 'common sense' is a recipe for endless debates about whose sense is 'common'. I just do not believe that dealing with disruptive or antisocial editors can be made any simpler... well that's what I think. Erich 00:34, 3 Aug 2004 (UTC)

quick polls, response to Mike Snow

Have a look at [Wikipedia talk:Quickpolls]] yourself, but I am at a bit of loss to understand your comment Mike. The results of the review poll were:

1. yes. continue using quickpolls (17)
2. yes in limited circumstances (16) inc some double votes
3. no (13)

I couldn’t see anybody complaining that quick polls were too complicated. I could see a lot of complaints that it just didn’t work. The problems as I read them were

1. it was too slow - WP:DWDAE takes three warnings and three admnins
2. it was a popularity contest (that's why the limit on who can vote)
3. it brought up frivoulous complaints (this is tight in DWDAE)

so geez... am I missing something? Erich 12:14, 28 Jul 2004 (UTC)

I didn't mean to suggest that quickpolls failed purely because of their complexity, although I do believe complexity may have contributed to it. My point is that quickpolls were about as complex a process as the community can handle in dealing with disruptive editors, without delegating/assigning that responsibility to something like the Arbitration Committee.

In my observation, as the quickpolls proposal was implemented, most problems that cropped up with its practical application were dealt with by developing more procedures. Thus the process increased in complexity as it evolved, even if that's not the primary reason people became increasingly dissatisfied with the process.

I think it's fairly clear that this proposal is already more complicated than quickpolls ever were. Furthermore, it's only theoretical, and inevitably will have to deal with new concerns should it actually be implemented. The most likely response will be to add more regulations to the process, as this is a common reaction in community dynamics of this sort. So I see a process that is not only overly complex now, but that I expect to get progressively worse as time goes on. As a result, I don't think it should be adopted. --Michael Snow 18:05, 30 Jul 2004 (UTC)

I dunno Michael. I'm at a bit of a loss really.

This step wise approach is pretty standard practice for managing difficult people. Its well proven and works better than most people realise. The only bit that is really original is the sock-puppet provision (to address a specific Wikipedia issue).

I really think it would be false economy to try to simplify this any further. A simple solution that does not work is not actually a simple solution.

Although I'm becoming resigned to the current round of polling going down I'd still ask you to reconsider supporting a two month trial. best wishes Erich 02:49, 4 Aug 2004 (UTC)

Uninvited company wrote:

Erich, all,

The policy is far more mechanical and convoluted than other Wikipedia policies. While I applaud your effort and share your overall goal, the policy as written is way too complicated and hard to follow:

UC (I’ll interpolate my reply into your comments) Well I think this is why we need a trial. To make the policy work, it is not a requirement for people to understand the detail of the policy. For example, we drive our cars/ride our bikes on the roads every day with a tiny understanding of most of the 100's of pages of legislation that govern road use. Erich 04:07, 4 Aug 2004 (UTC)

1. In practice, as the policy reads now, giving warnings/awaiting consensus/giving warnings/etc requires far more effort on the part of the upstanding wikipedians than evasion of the same by the troublemaker. It takes a lot of time and effort to come up with the minimum of nine (I think? it isn't clear whether a diff is required to document every actionable violation) diff links required to follow the whole process. It would take over an hour for most admins to put together the diff links and the rationale for each one, because it is a manual cut-and-paste process requiring typically about 10 page loads per diff (to find the right ones). And it is not fun (try it sometime). An hour of boring work to justify a 24 hour block is just not worthwhile.

Well I’m starting to think 10 may be too many. Personally I’d be happy with 6 or 8. 4 would be very strict, but I wouldn’t oppose it. But I think it would be a bit misguided to go searching for the 10 diffs in the first place. The way I imagine this working is that if one user was having trouble with somebody they could present their list of 2 to 4 diffs to kick off the process. Often that would be the end of the matter. If the use kept having problems they could keep gathering the diffs. If they were feeling annoyed they could give the other users’ edit history a scan as well to find more. If other users were having a problem they would add some more diffs etc. The onus is not on the admin to go and find them all… unless they are in the mood of course. The two difficult users I’ve encountered (both subject to adverse AC rulings) would have racked up ten extremely quickly — months before the AC finally acted. Importantly this isn’t a race to get the user blocked. (In fact you could argue the less people that get blocked on the policy the more effective it has been).

For the recalictrants the bar gets lower and lower. So repeat offenders waste less and less time.

1. There are too many outs for the problem users. "But I was warned two months ago and rehabilitated myself" -- "hey, you gave me a ---- but my edit wasn't as bad as Louie's and you only gave him a --" -- "but the first warning was for something different than the second warning" -- "those two users are carrying out a witch hunt" -- "but I haven't used that userid for 120 days so now I get to start over" -- "but I made 50 minor edits" -- "but that wasn't a personal attack, it was fact." Better to adopt a judgement-based policy and give examples to use for guideposts.

Now you’d know there is absolutely no need to reply to this sort of drivel. And who said admins should stop using judgement? Each admin reviews the diff for themselves. The ---‘s are just there as a guide – I think they’d be useful if the there were more than the required number of diffs but some were a bit borderline. You could just scan the ones with the most minuses first until you were happy the threshold was reached.

And who said admins should stop using judgement? What the policy says to admins is (a) users have to be warned a couple of times before they are blocked (b) you need to demonstrate why somebody should be blocked (c) you cannot block first-time offenders until they have made at least ten counter productive edits and (d) except in very limited circumstances, you need to have the support of your peers before you apply a block. Erich 04:07, 4 Aug 2004 (UTC)

1. Initial policy should focus on the basics. Lone ranger blocks? Drop it. Socks? Deal with it under a sock policy. Get the main part of this policy on the road first, and then add these sorts of tweaks later.

The policy was developed by a group editing process that involved both hawks and doves. I’m a bit reluctant to cull it untried because having thought about it a fair bit it is all reasonable.

Socks have to be dealt with. There is no way around it. We either deal with them up front… or wait till the socks appear and then scratch our heads!

The lone-ranger blocks I’m not a big fan of. But I can see the rationale.. and the doves and hawks beat out a good compromise between them. Erich 04:07, 4 Aug 2004 (UTC)

Compare what you have done to successful policies, such as WP:NPOV, WP:RFA. And consider marginally successful policies such as the deletion policy and WP:RFC. And as for quickpolls, I believe that it failed because the results weren't what the community expected and wanted. My view is that it was a) too easy to game, and b) gave troublemakers another soapbox. Your proposal, IMO, could potentially suffer these same failings if it were implemented.

I’ve tried to reply to the complexity issue in as many different ways as I can. Perhaps the best thing I can now say is: why not give it a go? If it doesn’t work then we’ll have a better idea of how to fix it or we can just ditch it. I actually think it would be very hard to game. The tension between stamping on socks and not biting the newbies is a real problem. But between us I think we came up with a pretty fair compromise. Any system that concludes with a block will face the same issues. All of Wikipedia is a potential soapbox I can’t see how this policy makes that worse?

I hope that one day Wikipedia may be taken seriously as a source of information. The question reviewers will ask is: "OK, you say this is the encyclopaedia that the Internet wrote, but you admit you excluded some people. How do you refute the claim that this is a biased view by an unrepresentative cabal?" If we can point to this procedure and show the grounds for blocks that were actually used, then this question is answered. I think this is a significant reason for not being satisfied with relying on "common sense" without being able to provide evidence.

Thanks once more for taking the time to spell out your concerns. I genuinely appreciate your effort. I hope these replies make some sense. Rather than deleting already written sections that seem reasonable, I'd still rather we gave it a go as is and then went from there... Erich 04:07, 4 Aug 2004 (UTC)

The thing that concerns me most about Erich's statement here is that it suggests that this policy is responding to an allegation that our critics haven't made. Wikipedia certainly has it's critics, and certainly about the accuracy of its information. But "a biased view by an unrepresentative cabal"? Don't make me laugh.

"In practice, as the policy reads now, giving warnings/awaiting consensus/giving warnings/etc requires far more effort on the part of the upstanding wikipedians than evasion of the same by the troublemaker." I think this quote from above says it all. You may state now that 10 diffs is too much, but remember who pushed this to a vote ASAP. Anyway, this was a step in the right direction, but far, far, far too complex. Maybe next time we'll get it right. Ambi 06:34, 4 Aug 2004 (UTC)

Gedday Ambiv, (have you changed your name? I quite liked your old one!) Please don't misunderstand me. I am not making the above accusation. I've seen more than enough so I agree it is utter rubbish. However, I've seen the accusation made more than once and it gets peoples backs up. So I just think it is important we can demonstrate that it is not true. Being able to demonostrate the grounds for excluding disruptive users is an excellent way of dismissing the concern.

I think justice is important in any endeavor and the ability to review the grounds for a decision is a key component of dishing out justice. If the grounds aren't presented then the decision cannot be reviewed. This policy doesn't just address editorial rules it excludes people from the process - admittedly not for very long... but it wouldn't really take very long for people to find themselves on the wrong end of rolling 4 day blocks.

I must say I don't really regret sticking to the original timeline. We gave everyone over two weeks, which was long enough for people interested in contributing to make a contribution. We needed to flush out the silent majority to see what they thought - and this poll did that. At this stage I'm thinking we let this vote run through then have another two weeks of editing based on the experience of the poll then back we come... there's no rush really.

Maybe at the next poll we will have a couple of options to consider? There is a strong push to simplify this drastically. I think I'm too attached to the current alegedly complex version to want to take part in a "simple justice" proposal so maybe the best course is for the proponents of the "simple justice" system should fork the proposal. We could bring back both versions for polling starting midday (UTC) August 22. just an idea... best wishes Erich 07:15, 4 Aug 2004 (UTC)

Yes, but on a trial period does not equal yes

I don't think it's appropriate to add the yes and yes, buto n a trial period votes together. In fact, I think it's best to get rid of the on a trial period vote at all, because it always has been and always will be the case that any policy can be changed or removed (or created) if through the proper channels. You could easily rephrase the question "no, unless on a trial period", and then add it to the no votes. { MB | マイカル } 17:16, Aug 3, 2004 (UTC)

Gedday Mbecker, You may have a point. Its a bit late now. We had the draft poll up for a week before it opened for taking comment and formualating the rules. Erich 01:53, 4 Aug 2004 (UTC)

As no consensus has been reached, it's not too late to fix it next time. If this proposal isn't going to get scrapped, then there's going to need to be another vote anyway. But I think MB is missing the the point of combining the votes. Someone voting yes would almost surely also support yes as a trial period. So if there would have been consensus for yes combined with yes for a trial period, then we should run a trial period. anthony (see warning) 17:00, 4 Aug 2004 (UTC)

I agree with Anthony - but I interpreted what was written that if there would have been a consensus for yes combined with yes for a trial period, then there would have been a trial period. Which interpretation is correct? It would certainly have been grossly "unfair" if a vote derived from combining the two votes would have lead to running the system without a trial period. Elf-friend 17:56, 4 Aug 2004 (UTC)

that's right Elf-friend- a combined vote success of a+b would lead to a trial period. Erich 19:32, 4 Aug 2004 (UTC)

"I agree with Anthony - but I interpreted what was written that if there would have been a consensus for yes combined with yes for a trial period, then there would have been a trial period." I'm not sure where I was unclear, but I interpreted it the same way. anthony (see warning) 18:03, 4 Aug 2004 (UTC)

Since there is no clear consensus, even if the yes-permanently and yes-trialperiod votes are considered together, this discussion is largely academic.

Bearing that in mind, I would suggest that since there is no precedent for "trial periods" for policy, one should not be implemented without a particularly clear mandate from the community.

UninvitedCompany 03:16, 5 Aug 2004 (UTC)

Actually there is one precedent, which is that quickpolls were implemented with a trial period of 30 days, and when we reviewed them afterwards, the consensus in favor was not as clear, so the policy died (albeit with a few spasmodic jerks post-mortem). I think trial periods can be handy when attempting solutions to intractable problems, but keep in mind that they give the critics of any policy a second clear chance to kill it. --Michael Snow 00:18, 6 Aug 2004 (UTC)

I agree on both counts... that is why you have a poll isn't it? ;-) Erich 04:10, 5 Aug 2004 (UTC)

mending problem areas

I think we should go back to the drawing board and address the objections, such as the policy being too long and complicated (it is) and it's placing more power/status in the hands of sysops (it shouldn't). As I pointed out before, if this policy were implemented, it would provide my first and only reason for wanting to be a sysop. Lets find a way to remove that incentive, shall we? ;)

Sam [Spade] 03:34, 5 Aug 2004 (UTC)

Gedday Sam, In terms of simplifieying... I'd suggest culling:

1. the lone-ranger blocks going (never been a fan)
2. the need for the link to two friedly warnings in the step one warning
3. maybe reducing the number of counterproductive edits from 10 to 8 or 6 for first offenders.
4. maybe reducing the number of admins to block to 2 (not keen on that really)

I couldn't cope with much more simplification than that. I especially think the sock and multiple offender provisions need to stay. What do you think? Erich 04:18, 5 Aug 2004 (UTC)

1 definitely needs to stay. If that goes, in any future amendment to this, I'll vote against it, regardless of anything else. 2, 3 and 4 are good ideas. However, while this slightly simplifies the procedure, the wording of the policy is still far, far too long, and I don't believe such small amendments will address the majority of no votes, although they would certainly be a step in the right direction. Ambi 07:45, 5 Aug 2004 (UTC)

that's not very helpful ambi. Consensus? Erich 13:04, 5 Aug 2004 (UTC)

I like the idea of a formal warning (this is not #2, I presume). One problem I've always had with admins is that they like to "warn" people for things that aren't really policies. This at least clarifies the point that yes, this is really something the admins are going to act on and not just a rogue admin. One thing I'd like specified is that warnings themselves may be appealed to the arb committee. Presumably anything may be appealed to the arb committee, but I think explicitly saying it here will give that a bit more liklihood to be accepted. anthony (see warning) 10:30, 5 Aug 2004 (UTC)

I do think there needs to be two warnings - one friendly the next one a bit sternerr. I'm talking about deleting the current provision that the first warning that requires two informal warings before the first warning. As for spelling things out... well you say it yourself... anything can go to the AC and with people baying baying for brevity I think the less we have to spell out the better! Erich 13:04, 5 Aug 2004 (UTC)

Perhaps we're just arguing semantics. I agree the user should be pointed to the policy before getting a formal warning. But I don't think that should be in the form of a warning. It shouldn't be threatening, it shouldn't be made with authority, it should just be a simple "hey, there's this policy against what you're doing, check it out." anthony (see warning) 10:47, 6 Aug 2004 (UTC)

I agree there should be a friendly reminder of the policy before a formal warning. I just don't think this needs to be spelled out in legalistic detail in the policy. Just say that a user should have been made aware of the policy before a formal warning can be sent. anthony (see warning) 13:32, 5 Aug 2004 (UTC)

Jimbo likes the voting scheme, and I suppose voting is better than just blocking. My biggest problem with voting is that it seems to remove responsibility from the admins. They can feel free to vote for someone just because they disagree with them, and even if the arb committee smacks them down, there's nothing that can really be done, as they were merely voting. I'm not sure how to solve this. anthony (see warning) 10:30, 5 Aug 2004 (UTC)

I think I agree with your earlier support for the AC. This policy should lighten the load on the AC not eliminatte it!! I think the best way will be deal with this is through gradual refinement of the policy and the related ones. Erich 13:04, 5 Aug 2004 (UTC)

But it seems all the AC can do is express its disapproval of a block. The block will have already been over by the time it hears the case, and the AC can't really censure and/or deadmin someone just for voting. anthony (see warning) 13:32, 5 Aug 2004 (UTC)

I really hate the provisions for extending the blocks past 24 hours (multiple offender provisions). I don't see admin blocks as a tool to solve ongoing problems. Maybe one way that it could be solved though is that a formal warning stays even beyond the first block (for some time period, maybe 90 days unless revoked by the arb committee). Then admins wouldn't have to go through the whole process over again for "repeat offenders".

The sockpuppet parts are bad, IMO, and perhaps it would be best to leave them to a separate proposal. It may be a necessary provision eventually, but without them this policy still can take care of a large percentage of the cases which don't involve them (and I suspect sockpuppets will be blocked unilaterally anyway).

I dunno Anthony.. if we don't deal with socks then it does all seem like a waste of time to me. Socks have just gotta be dealt with a the current proposal was carefully crafted to avoid biting newbies while not giveing the socks equal rigthts - if they are complicated... well sorry mate - it is not a simple problem. Erich 13:04, 5 Aug 2004 (UTC)

It's not a simple problem, and that's one of the reasons I don't think we should be spelling it out now. First of all, we should see what the details of the actual problem actually are before making policy on it. It seems like we're just playing mind experiments about how this is going to go now. Secondly, I think there needs to be a lot more input into any type of sockpuppet proposal. Adding sockpuppets to this proposal is just too much. Finally, I think the two can easily be separated. This proposal can weed out the longstanding problem users and mainly all that's left is enforcing rules against new users who do virtually nothing but problematic edits. anthony (see warning) 10:52, 6 Aug 2004 (UTC)

As for the rest, I'm not sure we need it. I've said already that I think the definitions section can be reduced to a simple "violating policy". The warning provision protects users in the case of that being overbroadly interpreted. At worst a user just has to stop the behavior which is warned until appeal is made to the arb committee. If I'm missing any other details, let me know. Maybe the best idea would be to make an outline of the important points and then rewrite everything. In fact, maybe we could have a quick poll on the outline, to solve the major issues first, and then worry about the details.

anthony (see warning) 10:30, 5 Aug 2004 (UTC)

So on what grounds would you support 24 hour blocks for violating policy, Anthony? I'm a little bit confused here. Ambi 10:55, 5 Aug 2004 (UTC)

oooh... good question! (I'd quite like to know that for all the people that voted against really) Erich 13:04, 5 Aug 2004 (UTC)

Ambi, I'll come up with a simplified proposal. I don't think it should only be admins voting, but I'll try to work with that. I've largely outlined it above. A formal warning, agreed to by the number of admins needed to certify a block. This warning should be explicitly reviewable by the AC, and should not expire upon someone being blocked. It should expire after a certain period of time, not to exceed 90 days (though I might initially propose 30). Non-admins should be encouraged to comment on the warning and vote in a separate section from the admins. Their votes will not be counted, but they might be considered by the arbitration committee if there is a lot of opposition. If the warning is not heeded, then admins can block upon agreement (2d+3). anthony (see warning) 13:32, 5 Aug 2004 (UTC)

On the basis of that description, I think that would be an excellent solution, and one which would be fairly likely to pass. I also like your idea of encouraging non-admin participation, as far as comments go. The one problem with opening up the actual vote is that would effectively reinstate the failed quickpolls. The only place I disagree with you there is the 2d+3 basis for blocking, but that's another matter.

Also, there was one of your posts above that I forgot to respond to earlier - that of responsibility. I think sysops do need to be responsible here, particularly for a nomination, but also for a vote. If it's a particularly frivolous proposal, then they deserve to be dragged over the coals by the AC for that. Ambi 13:48, 5 Aug 2004 (UTC)

Wikipedia:Dealing with disruptive or antisocial editors/simplified draft. Note that many of the cut portions, which were probably meant to deal with hypothetical situations, can always be added later. As for the 2d+3, what would you like to see? I personally would like to see a higher number, but this seems like the appropriate compromise.

Regarding responsibility, I don't think things will ever be as clear-cut as to call it frivolous. But as long as the warnings are reviewable an editor would only need to cease a particular behavior while waiting for the arbitration committee to review it, so not very much harm would be done (I've also limited the blocks to 24 hours at a time, which also limits the potential harm). anthony (see warning) 14:59, 5 Aug 2004 (UTC)

another way forward

Here are some ideas:

• Let's focus on the sock puppet problem for a while instead. Nearly all disruptive users use sock puppets. There are some suggestions for dealing with this at Wikipedia talk:sock puppet and also some related discussion at m:Draft privacy policy. The most effective Wikipedia policies are those that use differential effort (make problem activities harder for troublemakers to enact than for others to undo). Some technical and policy ideas for this regarding socks have been proposed.

• I also believe that the increased focus on Wikipedia:No personal attacks is valuable, and believe that there is room for some careful work there.

• While there have been few concrete proposals, there has been discussion of admin "accountability." While I believe "accountability" misses the mark somewhat, I think that we can and should make more of an effort to limit ongoing adminship to people who respect project norms. If we reform or dismiss any impulsive sysops we might have, and have a process in place for that, it becomes more palatable to give the remaining admins some discretion. I think the recent "accountability" pseudo-vote has done a disservice to the community by polarizing and making light of a serious issue.

• Once these areas are properly addressed, I believe the matter of "disruptive users" may be riper for consideration.

Respectfully

UninvitedCompany 18:12, 5 Aug 2004 (UTC)

UC, more power to your elbow with the above. I think we need to aim for progress on all fronts. Erich 06:37, 6 Aug 2004 (UTC)

A couple thoughts. I would differentiate between people who create sockpuppets (Lir) and those who use serial accounts (EntmootsOfTrolls reincarnations). More actively discouraging sockpuppets will probably work better in dealing with the first type. Also, I would say that a number of disruptive users (Paul Vogel, the so-called Mr. Treason) are operating purely from IP addresses. So while I don't mind pursuing that angle, I'm less confident that it will be particularly effective.

With respect to admin accountability, my current emphasis is to seek out and nominate new candidates I think will have good judgment, to improve the quality of the overall admin pool. Dismissing current admins is virtually impossible, and at the very least, I don't see any model for how to pursue that until the arbitration committee actually decides to use that sanction in one of its rulings. As for reforming anyone, we can try and bring community pressure to bear, but some of the most impulsive are also among those most set in their ways.

We could begin with the idea of withdrawing adminship from those admins who are no longer active in the project. That might start a shift away from the culture in which admins have life tenure. --Michael Snow 00:51, 6 Aug 2004 (UTC)

dealing with 'disuptive admins' is a bit of a different topic. I personally do not see much point in withdrawing admin status from inactive users though. People get busy in their real lives... if they have proved themselves to be sensible people with sound judgement then why demote them just because they have other committments? I think admins need to be judged on the quality of their contributions rather than quanitity. It would be a reasonable expectation that returning admins review changes to policy though I guess... Personally I think the recipe of warning twice and then acting with escalation of penalties for repeat offences applies equaly well to admins. The only difference is I think the AC may be better placed to judge the appropriateness of admin behaviour Erich 06:37, 6 Aug 2004 (UTC)

To Michael Snow's point, the distinction between sockpupets and serial accounts may be germane, though both create problems, at least in the cases we're aware of. I suspect there is a great deal of behind-the-scenes sockpuppetry that goes unnoticed.

While Vogel and others who edit from IPs can be disruptive, they have a) less protection from the community, both in formal policy and tradition; b) are more readily IP-blocked, and c) we have a practical means of recourse through ISPs, at least in theory. The main thing that needs done in this area, IMO, is that some AOL-specific policies and technologies need to be in place.

With regard to adminship, I believe some sort of periodic review is called for, something minimally disruptive but that would provide some means for reviewing sysop-specific actions. Consider: (1) establish an annual review policy, (2) pick ten people to do reviews, (3) set clear guidelines (4) randomly assign two reviewers to sysops each week, (5) if reviewers agree that everything is OK status is renewed, (6) otherwise there's community discussion. Lots of room for improvement, but the point is that we can purge the list of inactive administrators, have some sort of checking in place, and avoid a public spectacle. Erich, "disruptive" is probably too strong a word, IMO, it's the admins who don't at least make an effort at Wikipedia:No personal attacks, mainly, that I'm concerned about, and those few who have demonstrated a disregard for community norms through pursuit of really lame protection/deletion/block wars.

UninvitedCompany 03:24, 7 Aug 2004 (UTC)

Well, where do we want to have the discussion of periodic reviews - Wikipedia talk:Administrators? Have we thought about whether we're ready to take on that challenge? My guess is that as more of the community becomes aware of the idea, there will certainly be some concerns to deal with. A segment of admins may be rather attached to their status, and be pretty vocal about it. On the other hand, there's a large non-admin population that might be inclined to support the idea, but we'd have to reach out to them before many would speak up.

Whatever the precise structure of any review system, I seriously doubt our ability to avoid public spectacles. There will always be considerable pressure for transparency in decision-making, and this will likely force much of the process to be held openly. And certain segments of the public will naturally gravitate to the resulting spectacle. --Michael Snow 04:57, 7 Aug 2004 (UTC)

(snip)take out straw polls(/snip)

Are all these polls really necessary?

Frankly, I'd just like to see Anthony's proposal put to a vote, as I believe that it covers all the relevant points with much, much more simplicity and less rigamarole. If Anthony's had gone to a vote instead of the current one, I think it would have passed much more easily. Ambi 10:36, 6 Aug 2004 (UTC)