Wikipedia talk:Quasi-protection

Admins are the bottleneck

This is a proposal I've seen before. The primary problem with it is that administrators are the bottleneck - they simply can't promote users quickly enough and their time could be better used for other things. Maybe if distinguished users could promote new distinguished users? Or maybe if they make X edits and have an account for 4 days without receiving a complaint? I don't know. Deco 22:59, 27 May 2006 (UTC)

Why not reform sprotection so that the four days runs not from the day an account is created, but the day of the first edit. FearÉIREANN\^{(caint) 23:06, 27 May 2006 (UTC)}

I like Jtdirl's idea. The quasi-protection system is good, but adds a lot more hassle; it might be worth tweaking the sprotection system a bit and seeing if that staves off the vandalism for a while before putting in a major new layer. Shimgray | talk | 23:09, 27 May 2006 (UTC)

Hmm, also an interesting suggestion. In reply to admins as the bottleneck: I admit, this is a potential backlog, but I don't think that it should be a major issue: first, distinguished users would have no real benefits except for quasi-protected pages, which would be extremely rare, thus lowering demand. Secondly, most people wouldn't know about this until they reach a quasi-protected page. Finally, it would only take a few moments to quickly review a user's contributions - an admin could easily review 10 or more users in a minute, scanning their contributions. I'm sure we would find enough people willing to help at all times that no backlog would be created. Thanks for the comments! Flcelloguy (A note?) 23:19, 27 May 2006 (UTC)

No source images and the like can be cheacked in a couple of seconds. there have been backlogs.Geni 23:23, 27 May 2006 (UTC)

Why not just amend the current semiprotection policy and extend the timespan for new editors to 5 days from when they make their first edit and also make them have 50 substantive edits?--MONGO 23:23, 27 May 2006 (UTC)

Agreed needs a number of edits. Just 1 wouldn't be too high a bar to meet and not enough for any vandal to be banned. Make it 50 or so and if they get to 50 without being blocked it probably outweighs the damage they could do after reaching that bar. --pgk^(talk) 23:27, 27 May 2006 (UTC)

50 edits is a good idea; if the account only turns out to be vandal after 50 edits, the good edits made to get them over the quasi-protection boundary would outweigh the vandalism. How about automatic promotion on reaching 50 edits, which can then be taken away by any admin, as a kind of less extreme block? smurrayinchester^(Talk) 10:50, 28 May 2006 (UTC)

As much as I would love to do promotions, I don't think that would work, as least not if it were given out as liberally as suggested. Prodego ^talk 01:06, 28 May 2006 (UTC)

No.

Screams wheelwarring for controversial users, very much so a waste of time for Administrators, extensive changes needed to Mediawiki, additional DB stress, etc. The effort's really appreciated, but this sort of thing won't be efficient enough to handle sleepers. --Avillia ^{(Avillia me!)} 23:17, 27 May 2006 (UTC)

People aren't going to apply for promotion (and that's how it will be taken - as a promotion) only when they actually want to use it, they'll do so as soon as they feel they deserve it. You're talking something like 50 a day, and that's only once everyone that deserves it already has got it. It will take about 3 minutes per person, that's 2.5hrs a day. That's a lot of time spent on very little gain considering how easy it would be to get around - it means vandals have to make more effort, it doesn't make it harder. Having distingished users promote others would make it far too easy to work around - you just need one account to get promoted and you can do what you like. The next obvious suggestion is yet another rank of people that aren't admins, but can promote people to distingished, "and that way lies madness". I quite like Jtdirl's idea, though. --Tango 23:19, 27 May 2006 (UTC)

Apparently my estimate differs from yours. :-) I don't think it would take quite that much time - a brief glance at the contribs, making sure that they're not all minor edits to a category or something that a bot could do, randomly open one, and then promote - it should be given out quite liberally. I also don't think that wheelwarring will be a problem, because quasi-protection would only be applied to pages under vandalbot attacks, and not for content dispute. There's nothing to wheel war over - either you're a vandalbot or you're not. :-) Thanks! Flcelloguy (A note?) 23:23, 27 May 2006 (UTC)

Take reformed vandals, people who go against the veritable 'grain' of the Wikipedia community, people who generally make widely differing opinions among administrators. Half of them will want to distinguish, half of them don't trust them, and one member of this controversial group will be wanting to edit a quasi-protected article. --Avillia ^{(Avillia me!)} 23:27, 27 May 2006 (UTC)

You have to take into account the time it takes to load each page of the process. You'd need to load their user talk, their contribs, at least one of their diffs, and the actual promotion page. When everything is going well, that would only take a couple of seconds per page on a fast connection, but wikipedia often slows down to the point that it would take a minute just to load all the pages. Anyway, even 10 seconds a person is still nearly 10 minutes a day not spent on other things... An admin can do a lot of useful stuff in 10 minutes... --Tango 23:42, 27 May 2006 (UTC)

Two scenarios

Either there will be few distinguished users because few ask for it thus Quasi-protection will be pretty much the same as full protection or it becomes a major resource drain for admins. An even then will be a fairly hefty form of protection.Geni 23:22, 27 May 2006 (UTC)

I don't understand what you mean by a "hefty" form of protection. As to too few users: because this will be given quite liberally, that shouldn't be a problem. If a user comes to a quasi-protected page, which will be quite rare, and wishes to edit it, all they have to do is make a request. See above for replies regarding admin drain. Thanks! Flcelloguy (A note?) 23:25, 27 May 2006 (UTC)

People want to edit pages right now they do not want to have to wait however long it takes for an admin to notice thier request. More likely the protection will be gone before an admin answers it.Geni 23:43, 27 May 2006 (UTC)

Simulated annealing

I think we need some sort of way to implement simulated annealing. --HappyCamper 23:28, 27 May 2006 (UTC)

Er, can you elaborate? The analogy is lost on me. Deco 08:36, 28 May 2006 (UTC)

Create a MediaWiki edit counter?

From the proposal it sounded like the only thing that held the original semi-protection policy back from using edit counts is that MediaWiki doesn't currently keep track of the # of edits someone has. Since several people have suggested just changing the semi-protection policy, and adding a new quasi-protection policy would require a fair amount of new code and admin responsibilities, would it be potentially simpler to create a MediaWiki edit counter that will give them the right to edit semiprotected pages after X amount of edits, rather than (or in addition to) the current 96 hour rule? MediaWiki wouldn't necessarily need to have a variable that constantly keeps track of how many edits a person has at any given time; I figure it could be done one of two ways: 1.) Once they reach that critical point, it could give the person a flag similar to the "autoconfirmed" flag, and never have to worry about it ever again, or 2.) There's already a fair amount of code out there to count edits, so the software could count the number of edits a person has every time they try to edit a semi-protected page; it should be fairly fast to do such edit counts, as all it would have to do is count up until X number of edits, and then stop. Any thoughts? EWS23 | (Leave me a message!) 23:57, 27 May 2006 (UTC)

I had forgotten about the issue of not being able to implement the edit count thing when semi was being developed. I support bugging developers with this again, if indeed it is feasible.--MONGO 00:13, 28 May 2006 (UTC)

I'll ask Rob Church about this. But the potential problem with this, while an improvement, is that vandalbots could easily automate the accounts to make several trivial edits - i.e. create a user page, and fill it with random junk. However, it would be better than the current semiprotection in terms of stopping vandalbots. Thanks! Flcelloguy (A note?) 00:15, 28 May 2006 (UTC)

I support this idea. It should do a quick check to see if any edits were in the articles namespace (25 or more). I'd like it if semi-protection did both edit-count and 1% newest user checks, that would stop a LOT of crap.Voice-of-All^Talk 00:51, 28 May 2006 (UTC)

I too like this. I don't suppose a significative amount of vandals out there are "sofisticated" enough to circumvent this. Even if some will, I would think that we'd be able to get the large majority of them. Redux 02:49, 28 May 2006 (UTC)

To avoid the user page edits problem, as VoA suggested we could do a count of the number of edits in the main namespace. Accounts with 25-50+ vandalistic edits are generally indefinitely blocked anyway. Other vandals who try to do 25-50 productive/unsuspicious edits will either be wasting a fair amount of time and/or doing more good than harm. Hopefully newcomers who start doing near-null edits or spelling changes at a high pace will be identified as possible unauthorized use of a bot. I realize there are still ways to get through the cracks, but it's at least a start. EWS23 | (Leave me a message!) 03:07, 28 May 2006 (UTC)

Improving on EWS23's idea, I think a good way would be to first include the edit-counter in the MediaWiki. I can't see why it would be difficult. When I can count edits in Special:Contributions, why can't the software. Anyways, the improvement I am suggesting is that instead of creating a new type of protection(and a new type of user-level), why not just modify the semi-protection policy as:

"A semi-protected page can be edited by an editor only when their ε > 50",

where ε = "Total mainspace edits" - 50 x "Number of blocks".

Here I am saying that a block negates 50 good edits (but this is negotiable). Any comments? -Ambuj Saxena (talk) 12:33, 28 May 2006 (UTC)

A block might negate 50 good edits, but your proposal doesn't say "good edits" it says "Total mainspace edits". A vandal (especially a vandalbot) can make far more than 50 edits per block. Yes, they'll get indefinately blocked soon, but not soon enough if they're determined. How about any block in the last month makes you ineligable? Also, how about 50 edits *since the block*, and then 24 hours after the 50th, negates the block, but only a block from more than a month ago? That's rather complicated to code though, I guess (not impossible, but harder than a simply edit count). --Tango 13:00, 28 May 2006 (UTC)

I think 50 edits is too high for legitimate new users. The difference for a vandal between 10 edits and 50 is negligible, especially if they are using a bot. For a new user, that can mean weeks or more, unless they are instantly addicted. 10 mainspace edits seems reasonable to me.--ragesoss 14:07, 28 May 2006 (UTC)

You can't teach MediaWiki to understand "good edits". Even if you could, the complication isn't worth it. As for Ragesoss' suggestion, we can make "ε > 10". Looking deeper into the problem, I think we should have bots (official Wikipedia bots) to take care of Vandalbots. There might be two ways for it to function. First would be a conservative way of running it. It will run only when a user tries to edit a semi-protected page. It will try to map its behaviour (say in the last 50 pages edited by it) to vandalbots. I guess Vandalbots will be making same changes to every page like re-arranging spaces, adding a word/sentence, etc. If the bot is able to map its behaviour to any bot-like edit, it will revert and notify the user like Tawkerbot2 does. The other way would be to monitor every user with less than 100 edits (assuming editcounter is incorporated in MediaWiki) and map their edits to Vandalbot's pattern. Comments/Suggestions? -Ambuj Saxena (talk) 17:34, 28 May 2006 (UTC)

Ageed. Remember KISS people. Lets just count article edits and see if edit>E, where E is 25, or 50 or whatever we set it to.Voice-of-All^Talk 00:50, 29 May 2006 (UTC)

I agree. Haukur 10:50, 30 May 2006 (UTC)

I like the idea of an automatic counter for all namespace edits. I think Ambuj Saxena's idea plus a miniumum time of five days should be needed to edit semiprotected pages. However, I do not support a new level of protection for reasons specified above. 72.139.119.165 01:04, 17 August 2006 (UTC)

Alternative or supplemental

I've been asked to comment on the technical aspects of this, but for now, here's another thought. If four days isn't long enough, why not ask us to extend it? We can do so without too much trouble, although the configuration setting might affect other related flags, e.g. for page moves, etc. robchurch | talk 01:24, 28 May 2006 (UTC)

Sleeper accounts will still sleep as usual, the point of this policy is to solve that problem by and large. I wish there was an easier way to kill sleeper accounts, but I no one can think of any yet. I would support changing 1 to 2% either way though.Voice-of-All^Talk 01:34, 28 May 2006 (UTC)

Agree with Voice of All with respect to upping it to 2%. I fear that the quasi-protection policy, as proposed, will be unworkable. bd2412 T 04:01, 28 May 2006 (UTC)

If this proposal can work (and I think it can, the only problem is retroactive edit counting...an initial server use bump), I'd like for it to be implemented, and 1% to be changed to 2% in addition (so spro will have a two pass check). If now, I'd at least like to see the 2%.Voice-of-All^Talk 07:09, 28 May 2006 (UTC)

Question:

• There has been a lot of people mentioning support for Jdtril's idea ('Why not reform sprotection so that the four days runs not from the day an account is created, but the day of the first edit.') Is this a technical possibility?

--Robdurbar 11:08, 28 May 2006 (UTC)

That would still be un-useful, because a bot that creates an account can be programmed to make an edit on that account the second it creates it. --GeorgeMoney ^T·C 17:41, 28 May 2006 (UTC)

Uh...

I don't see how this would be very helpful if applied to all daily FAs (see User:Raul654/protection, whose objections also apply to this proposal). If applied to only articles targeted by sleeper accounts, I would perhaps grudgingly accept it in the same sense that I accept that semi-protection is sometimes warranted. However, this proposal is just too m:instruction creepy for me. It doesn't make sense to have a requests page considering the difficulty of informing people about it, and the difficulty of getting them to apply (more work -> not nice). And even then, as others have said, admins would have a lot of work to do. Sleeper accounts are a relatively minor problem, IMO. It's not worth having such a targeted solution. Just semi-protect the articles they target and be done with things. Another thing worth doing might be pursuing their ISPs and, y'know, actually screwing them up the ass. Even if we can't get anything done legally, cutting these things off at the source is probably worth a try. Johnleemk | Talk 10:16, 28 May 2006 (UTC)

Agree, semi-protected should look at edit count, this system of having admins verify people will only lead to a big mess. How many pages would you think would be quasi-protected at a time? Probably not many, and for this very trivial benefit we now have to vouch for the intent of every user? This has scaling issues. Also, if the system is being added because a better system would entail changes to the code there are logical errors. This system will also entail changes to the code, so why not go ahead and do the better system (having mediawiki count edits) since both require code changes. - cohesion 21:14, 28 May 2006 (UTC)

For the record, I only support edit counting and the 2%. I do not think that an admin approval system would work at all, too much pile-up and wasted time.Voice-of-All^Talk 21:20, 28 May 2006 (UTC)

I like it!

But, instead of having people to be "distinguished" status, we could make it that people on WP:TRUSTED can be able to edit the pages. --GeorgeMoney ^T·C 16:35, 28 May 2006 (UTC)

Shared IPs

A proposal to prevent shared IPs from editing mainspace has shortly been rejected, but why not to make quasi-protected articles uneditable by unregistered shared IPs too? Unregistered shared IPs's users are many potential contributors; and with a sistem like this, they (who are the best vandals because of the possibility of changing IPs in seconds) will be able to edit most of articles exept vandal-routine articles. I beelive it is balanced between complete freedom and semi protection —Argentino (talk/cont.) 00:42, 29 May 2006 (UTC)

About WP:TRUSTED.

It needs to be expanded and then the developers will have to manage to do it, maybe a new kind of user access (trusted user?) will be an easyer way. But I think it should have at least 100 edits (for experience) and there should be a community's aproval, like admins, with at least 60% support.

About admin work.

Get more admins or try a list of trusted users. Voilà.

—Argentino (talk/cont.) 00:51, 29 May 2006 (UTC)

Or you could make it so each of the 800 admins has to approve 100 users a day for 14 days, and that's more than enough. --GeorgeMoney ^T·C 00:58, 29 May 2006 (UTC)

You say it ironically? It seems difficult to me that so many admins find so many people in shuch a little period of time without mistaking, anyway I was talking idealistically, we should ask a developer if blocking sleeping accounts is technically possible (identifying them). I'm leaving if you post i will answer tomorrow. —Argentino (talk/cont.) 01:09, 29 May 2006 (UTC)

There are some users who created accounts in good faith, and decided to come back after a year and contribute. --GeorgeMoney ^T·C 01:15, 29 May 2006 (UTC)

Shared IPs already can't edit semi-protected pages, because you have to be logged in to edit them. Unless you're suggesting logged in users using a shared IP should be blocked from editing certain pages, in which case I strongly disagree - there are plenty of very experienced editors that would be blocked under that rule. --Tango 10:33, 29 May 2006 (UTC)

No, i meant to block only shared IPs whithout normal IPs so we stop the most vandalizing Ip adresses. But definitely NOT blocking logged in users. I'd like it to be a half-way between copletely vandalizable and uneditable by logged-of, (ie not leting the article grow as much as it could but neiter letting it being vandalized as much as it could. —Argentino (talk/cont.) 23:51, 29 May 2006 (UTC)

You're looking for something that blocks fewer people than semi-protection? I think that's a whole new suggestion - the quasi-protection idea was meant to block more people. --Tango 12:05, 31 May 2006 (UTC)

A bot could promote

I think the bulk of promotion to the "distinguished user" status can be done by a bot. The algorithm might be complicated (like 24h. since the 50 mainspace edits since the last block and at least 48h since 20 mainspace edits since the last test message, and at least 1 month since the last block). The admins could manually distinguish/de-distinguish if the bot fails. The bot's algorithm could be make unknown to users to prevent gaming of the system. We could even set the distinguish user flag to static IPs if only good edits are coming from this account.

We could somehow separate the "new" and "distinguished" users by coloring in the RC/NA/WP lists - it would help the patrolling. abakharev 03:55, 29 May 2006 (UTC)

I much simpler pass test of User:Voice of All/History/monobook.js could do it. I'd rather KISS it though. Just check their contribs for 50 edits (or 100). Remember that deleted edits don't show up on contribs pages.Voice-of-All^Talk 05:29, 29 May 2006 (UTC)

The code on User:Voice of All/History/monobook.js looks interesting, I would like to add it to my monobook, but what it is exactly doing? There are two approaches to the deficiensies of the semi-protection - smarter sprotect (not 4 days since the acc creation but 4 days since the first article edit + num of edits +...) or just a simple bit in the user's database + smart bot to set the bit + manual overwrite. I am not sure what is easier to code, but the second system seems to be more flexible and safer. The approach based poorly on the number of edits (especially the number of the article edits) seems better than the approach based on time, but theoretically there could be a possibility that all the articles interesting for a user are semi-protected, thus, he cannot reach the number of edits , thus... I am not sure if the situation is realistic but it is possible. There are also accounts that regularly vandalize but make some productive contributions as well, I would like them to be kept off from the s/q-protected articles. abakharev 05:49, 29 May 2006 (UTC)

I would do this: 50+ articles edits/4 days min. Both are needed. Thats it. The only policy that can ever get through, and is for the best usually, is KISS.Voice-of-All^Talk 06:23, 29 May 2006 (UTC)

It's far too easy for a vandal to reach 50/100 edits. Blocks need to be taken into account. Deleted edits aren't counted, but reverted edits are, so 50 acts of vandalism over 4 days and you're a distingished user - that's not right. --Tango 10:37, 29 May 2006 (UTC)

How about 50/100 edits and four days since the last block? A few vandals may be able to get through, but that's no big deal since it would still be fewer than are able to edit semi-protected pages already. All in all, however, I would prefer this be automatic rather than committee. The idea of having two user tiers has always been an issue, and has never really gained momentum. There are other ways of "distinguishing" users... i.e. barnstars etc. --tomf688 (talk - email) 18:36, 29 May 2006 (UTC)

Bots are hacks, workarounds for missing software features. If we did it automatically it shouldn't be with a bot. Deco 18:39, 29 May 2006 (UTC)

Find a solution that doesn't give yet more powers to administrators

There is already far too much of a status distinction in Wikipedia between admins and non-admins. I do not want to have to go crawling to an admin for promotion, or risk being demoted by a rogue admin out of spite. The term "distinguished user" is patronising in any case. CalJW 22:39, 29 May 2006 (UTC)

It won't work, but we'll be stuck with it

There's a widely-cited checklist for responding to seriously-flawed proposed solutions to the problem of email spam. One of the responses on that checklist applies here:

(x) It will stop spam for two weeks and then we'll be stuck with it

This proposal, if implemented, will not stop the creation of junk accounts by vandals. That is, it won't work for very long. They will simply have to contribute a de minimis number of non-vandalism edits before going on their destructive spam sprees. This could easily be accomplished by vandalbots using spellchecking software or auto-correcting punctuation errors to improve articles in tiny ways. Or, for that matter, it wouldn't be too much work for a vandalbot owner to make manual improvements to a few articles for a few days. Once they get their "distinguished" bit, they can go rampage.

However, once this feature is implemented, we'll be stuck with it. That is, we'll be stuck with a new bit on user accounts that can be used to restrict them. Nobody in power will want to disable an "anti-vandalism" feature, just as nobody in power wants to repeal "anti-terrorism" legislation, even if it doesn't work. Moreover, this bit can be used to attack controversial users, impairing their ability to edit and work on articles. An administrator with strong opinions can lock dissenters out of an article by setting it quasi-protected and finding a pretext to drop the dissenters' "distinguished" bits. One side of a content dispute can whine to an admin that the other side is breaking some minor rule, and get their opponents locked out of the article. Where people should be learning to work with those with whom they disagree, tools like this encourage them to instead try to get an admin to lock their opponents out.

Right now, bias, credibility, and civility are much bigger problems here than vandalbots. We know how to clean up and block vandalbots. But we have not solved the larger problems of bias, and of the escalation of content disagreements into accusations of misconduct. We have likewise not solved the problems of administrators who choose to treat marginal users and clueless newbies as criminals rather than as candidates for education. This newbie-biting conduct has now created a corps of alienated schmucks who had a bad experience on Wikipedia and are therefore willing to join up with stalkers and libellers like Daniel Brandt in order to get back at us.

We don't need more tools for labelling users and nitpicking their conduct in the name of "fighting vandalism". We don't need more ways for people to give each other a hard time and lock each other out of articles for dubious reasons. We have too much of that already. And we certainly don't need finer-grained categories of restriction, more levels of hierarchy, and more ways of rubbing ordure in someone's face when they do something someone else doesn't like.

Forget this idea. Really. Throw it out. Delete it, trash it, ignore it. It's bad. Destructive, divisive, broken, and bozotic. It won't work for the intended purpose, but we'll be stuck with it, and it'll worsen our existing problems. Instead, work on fixing the civility problems and the escalation of content disputes into "BLOCK HIM!" "NO, BLOCK HIM!" spats. --FOo 22:41, 29 May 2006 (UTC)

Another thing that might happen is that vandals will wait 7 months, and then make their move. After 7 months, everyone will have let their guard down, and all pages will be Quaziprotected. --GeorgeMoney ^T·C 23:16, 29 May 2006 (UTC)

A solution may be that "untrusting" users was a community-consensused action. I am really against the bot because it lacks inteligence to make difference between edits, however it could make a "list of potentially trusted users, and with the vote of, lets say, 7 other treusted users, people on the list are made trusted too. We can start with only having administrators, bureaucats and stewards in the "trusted" status, so they can start "trusting" other users (who will trust other different users and so on) —Argentino (talk/cont.) 23:59, 29 May 2006 (UTC)

My opinion (short) is: may quasiprotection let edit only users with "trusted" status, who can give, with the aproval of 6 other trusteds, that same status to other candidates, and with the same requirements take of that same stat. may the first trusted users administrators, bureaucats and stewards because we should be able to trust them. —Argentino (talk/cont.) 00:54, 30 May 2006 (UTC) Trusteds are the way!

That might work. However it would probably require major software development in order to implement, due to the need for multiple users to promote. Also if 6 vandals got in, how would the status be removed? Prodego ^talk 01:28, 30 May 2006 (UTC)

None of these responses deal with the worst problem I discuss above. In order to be useful (temporarily) as an anti-vandalism too, a 'trusted' or 'distinguished' bit must be removed from user accounts of vandals or other troublemakers. But if administrators can remove this bit from users, then this will incite further abuse. By "abuse" here I don't merely mean abuse by administrators, but abuse of administrative process by contentious editors. Go read WP:AN/I for a while and see how often someone comes by asking for someone else to be blocked because they're the other side in a content dispute. This, if implemented, would invite more of the same: "You shouldn't be a 'trusted' or 'distinguished' user, because nobody trustworthy would have the opinion that you have."

People who spend their time trying to get other people blocked or restricted are themselves the ones with the problem. Rather than coming up with more blocking and restriction tools, we need to teach editors (and admins) that restricting the other guy is almost always the wrong thing in the long run. We need to build communication between disputing editors, rather than being in a big rush to declare the other side unreasonable and try to find some trickery in policy to get them blocked.

The proposal simply doesn't work to stop vandalism. But it does create yet another type of second-class citizen here, and a mechanism for demoting people to that class. That's harmful, and for that reason, this proposal should be rejected. --FOo 01:48, 30 May 2006 (UTC)

You know what - agree with the above. Robdurbar 16:26, 30 May 2006 (UTC)

You're suggesting we don't block vandals but rather try and talk to them? Do you really expect that to work? People that go around adding "is gay" to biography articles and keep doing it after multiple warnings are not very likely to listen to rational arguement. --Tango 22:25, 30 May 2006 (UTC)

Uhm. No. Vandals we block and revert, same as ever. Vandalbots can be deterred using mechanisms that target unauthorized bots. Neither of these problems require the creation of a new underclass of editors. Indeed, neither of these problems would be solved or even ameliorated by creating a new underclass.

Out in the world, terrorism is being used as an excuse for restrictions on civil liberties which utterly fail to stop terrorism, but are excellent at suppressing political dissent, creating underclasses, and justifying police brutality. Likewise, here, it seems that some folks want to use vandalism as an excuse to create whole new types of hierarchy -- which are predictably ineffectual at stopping vandalism, but which are great for edit warriors who want to block the other side. --FOo 06:05, 31 May 2006 (UTC)

Well, if we copy the RfA sistem, in wich only trusted users were allowed to vote, and someone needed 7 votes (Support - Oppose =< 7) to be promoted, let do the same to unpromote. To revoke trustedship to trusted users with a proven vandalism and 7 votes oppose is a nice idea, because pople won't be un-trusteded without strong evidence. Make technically possible for a trusted user to trust other users (with consensus) to avoid admin elitism and overpower. For 6 vandals to get in, they have to be trusted by comunity, so the first ones will have to be, in the beginning, good users. I don't think anyone will support somenone with the evidence of being a vandal, so they can be easly removed, i think it great to "create another type of second-class citizen here", if this is enough spread arround good users who can't be admins. We aren't taking privileges away from common users, we are giving them privileges. And new users could easily be "trusted" and there would be an intermediate status between "commons" and the "admin elite". —Argentino (talk/cont.) 19:19, 30 May 2006 (UTC)

You want a full RfA for everyone that wants to become trusted? That would take far too long. That's even worse than having admins selecting people that are trusted after looking at their contribs for a few seconds. --Tango 22:25, 30 May 2006 (UTC)

No, sorry, of course I didn't mean that, I said we could copy the RfA's system, that is, to have a community-consensused promotion to trusted, and proposed to have a number of votes, if you want it can be with a 51% or + of approval, but not to have an administrator selecting those users s/he likes. So, i'd re-write the policy:
This is how it looks now:

Administrators would have the right to promote new users to distinguished users, and this would be done quite liberally. Anyone with a "history" of good edits - for instance, 10 non-vandalism edits - would be promoted to "distinguished user". Administrators would also have the right to remove the status of "distinguished user"

This is how i'd like it to be:

Distinguished users would have the right to promote new users to distinguished users, and this would be done quite liberally, but whith a general consensus of the community. Anyone with a "history" of good edits - for instance, 50-100 non-vandalism edits (whole, not only mainspace)- would be promoted to "distinguished user". Distinguished users would also have the right to remove the status of "distinguished user" to people who become vandals (if supported by evidence and the community's consent).

—Argentino (talk/cont.) 00:31, 31 May 2006 (UTC)

That's self-contradictory. Either distingished users promote, or it's automatic at a given edit count. Both wouldn't work... And getting consensus to demote someone wouldn't work - we block vandals once we know they're vandals. A protection system is needed to stop people we haven't realised are vandals yet from vandalising particular pages. --Tango 01:03, 31 May 2006 (UTC)

How about we recognize that a fundamentally broken idea cannot be carefully tuned into an excellent one? Creating a new class of restricted users will not be effective at stopping persistent vandals, because the kind of people who want to be persistent vandals are, well, persistent. They are trolls. They get their rocks off by being more persistent than the admins trying to stop them, wearing the system out, and pissing people off. They are encouraged when you create new policy to try to stop them, because it makes them feel effective and noticed.

But at the same time that Virtuous Overbearing Hierarchy Addicts and Crooked Trolling Vandalism Addicts have their little arms race, ordinary editors are harmed. They are harmed by instruction creep. They are harmed by the growing complexity and unfriendliness of the system. They are harmed by being told, "You can't do that -- you aren't trusted enough yet!" They are harmed by malicious twits abusing the system to try to get their opponents demoted to peon status. (And that happens often enough now -- see WP:AN/I and WP:RFAr for the number of content disputes that some edit-warrior tries to win by getting the other guy banned.)

And the project is harmed by these things too. --FOo 06:05, 31 May 2006 (UTC)

I think you're right. Wikipedia is meant to be editable by everyone - we can get away with a few exceptions, but we can't stop vandalism completely while still having the encyclopedia editable by normal people. It's like copy protection (DRM) - it will never be uncrackable because it always needs to be possible to listen to the music, and you can't stop copying completely without stopping the listening. I think more useful suggestions would be ways to deal with vandalism once it happens. A more organised method of RC patrol or something. Trying to prevent it will only ever have very limited success. --Tango 12:11, 31 May 2006 (UTC)

If you have a better suggestion... —Argentino (talk/cont.) 20:54, 31 May 2006 (UTC)

I'd say leaving things how they are would be better than this idea. --Tango 21:21, 31 May 2006 (UTC)

Exactly. There is no problem here that can be solved with the creation of more underclasses. This proposal does not need to be tweaked; it needs to be abandoned. --FOo 04:32, 1 June 2006 (UTC)

No MediaWiki editcounter?

If MediaWiki has no internal editcounter, what counts the edits in the renaming log? Prodego ^talk 14:59, 3 June 2006 (UTC)

I believe that that's a technical restriction that makes it impossible if the renaming of a certain number of contributions is simply too high; I don't think it actually "counts" edits, per se. (Though I'm not sure about this; a developer would be more appropriate to ask.) Thanks! Flcelloguy (A note?) 15:51, 4 June 2006 (UTC)

KISS, KISS, KISS

OK, this is going nowhere. The only practical ideas suggested were a)block 2% instead of 1% of new users and b)get the devs to make an editcounter to check for X edits to edit certain pages. I suggest we focus on those proposals.Voice-of-All 05:59, 15 June 2006 (UTC)