Wikipedia talk:Requests for rollback/Archive 3

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

01 – 02 – Archive 03 – 04 – 05

Contents

Rejected

This proposal failed to gain consensus; a very active membership split 191/97 (hardly a thumping endorsement) and discussion has stalled. It's time to move on. John Reid 00:20, 2 April 2006 (UTC)

But hardly a ringing rejection. I'll be reverting you as well It's inappropriate to mark it rejected sincewhen people were voting in the poll just today (so it's far from dead, IMO). BTW, it's at a hair over 66% accept right now. —Locke Cole • t • c 00:30, 2 April 2006 (UTC) (amended 00:32, 2 April 2006 (UTC))
Well, the poll has to be considered closed, probably no harm in people voting I guess but it is closed. Generally 2 weeks is about it for these sorts of things. and back in January/early February people settled on 2 weeks [1] I think. You can't just keep a poll open until you get the result you want. Rx StrangeLove 01:21, 2 April 2006 (UTC)
There's been a steady stream of oppose and support votes since this poll was supposed to have ended, and as we work off consensus (which can change over time), I think it's kind of silly to close something that's this "close" to being accepted. —Locke Cole • t • c 01:23, 2 April 2006 (UTC)

This isn't a democracy and this isn't a winner-takes-all vote. At this moment I count 201 in favor and 101 against. Perhaps more importantly, comments on both sides are often lengthy and well-reasoned. Consensus demands that we respect both sides. Certainly we cannot wait until the precise moment that one side or the other gains some arbitrary supermajority, declare the other side crushed, and the proposal official. To do so will antagonize a large segment of the community.

If you don't close a poll, naturally editors will continue to participate in it. The community has given its evaluation of the proposal: Close, but no cigar.

As a rule, I don't believe in reverting registered editors for any reason. If it must be done, someone else may do it. I do ask that you consider restoring the {{rejected}} tag. Formally close the poll and let's move on.

There are expressions of support. If you are convinced the proposal has merit, you might want to try rewriting it to take into account the concerns of the sizable opposing population. John Reid 05:33, 6 April 2006 (UTC)

I concur with John Reid here. The current proposal has not gained a significant amount of support for the proposal (with respect to those opposed) and has not been implemented; as such, the current proposal should be tagged as {{rejected}}. Remember, though, that being tagged as {{rejected}} does not mean the proposal is dead. After all, this is a wiki, and if the community consensus changes in any way, the tag can be removed or changed. Thanks! Flcelloguy (A note?) 20:20, 6 April 2006 (UTC)
I wouldn't call that rejection. I'd call it abeyance. Sam Korn (smoddy) 20:23, 6 April 2006 (UTC)
This proposal has not reached the level of acceptance that most policies require (for instance, semi-protection's poll had approximately 100 supports to approximately 4 opposes. I was one of the opposes and have been pleasantly surprised with the results, but I digress...). Therefore, it is rejected; it does not appear that anything significant will occur that the community will come to such a consensus required for policies. Thus, until then, it should be tagged as {{rejected}}. Thanks! Flcelloguy (A note?) 20:41, 6 April 2006 (UTC)
Just because we're working on computers doesn't mean we have to think in binary. "Rejected" means that's it, it's done, all's over. Rejected must mean that there is consensus for something not to happen, not that there is a lack of consensus that something should happen. Clearly there is considerable support for the principle, so it is wrong to label this "rejected". Sam Korn (smoddy) 22:58, 6 April 2006 (UTC)
The proposal as it stands was not accepted and implemented, ergo it was rejected. What the poll demonstrated was that there was "no consensus" for the proposal as it stands. Those are the crucial words: as it stands. The poll does not reject all possible incarnation of all possible versions of RfR ever. Just this one. -Splashtalk 23:07, 6 April 2006 (UTC)
Clearly you didn't read what I just said. This does not have to be binary. There can be a state between adoption and rejection. Adoption is an action. Rejection is an action. We haven't done either. Perhaps a new template (gasp) {{notadopted}} would be in order for circumstances like this, where the principle meets with approval but the implementation is still being thrashed out. Sam Korn (smoddy) 23:11, 6 April 2006 (UTC)
Good template suggestion. I created it. Talrias (t | e | c) 23:16, 6 April 2006 (UTC)
Eek. Sam Korn (smoddy) 23:25, 6 April 2006 (UTC)
There is no consensus to reject. —Locke Cole • t • c 23:11, 6 April 2006 (UTC)
Yawn. Please don't patronise me, Sam Korn. Of course I read what you just wrote. I am afraid I must be aboslutely dead-set against your notion that the principle is approved by that poll and we are merely waiting for implementation. That is patently wrong. Rejection or not aside, that simply is not the case. -Splashtalk 23:14, 6 April 2006 (UTC)
Furthermore, it seems clear that if there should come a new proposal, it would need to go back to the community in the way that this did. -Splashtalk 23:18, 6 April 2006 (UTC)
I apologise. It was not my intention to be patronising. It was just that your comment didn't even mention my point, so I assumed you hadn't read it. I'm sorry. Anyway, principles cannot be approved by a poll. Polls can demonstrate approval, but they do not approve by and in themselves. I think it can reasonably be said that there was very general agreement that the basic principle was fundamentally sound. Or do you disagree with this? Sam Korn (smoddy) 23:25, 6 April 2006 (UTC)
Well, I think the poll probably only dealt with the actualy proposal as it stood. Some people object to the philosophy, others to the implementation, others to a bit of both or more one than the other. Since the poll didn't ask "do you support RfR in whatever form it might take", it's difficult to say that it can be used to answer that question. It demonstrated "no consensus" on the particular proposal made. It doens't pre-approve, reject or anything else a new proposal. It would seem to indicate that a different proposal may well exist that would acquire support. But I don't think it grants a license to create some new scheme and implement without returning to the community at large on the detail of that scheme. This is what I was after saying originally, and so I didn't particularly deal with your point head-on: to a (fairly large) extent, whether the original proposal is "rejected" or "no consensused" is academic since the poll doesn't allow us to pre-judge a new proposal that could be made. All that is clear is that the proposal as it stood didn't reach a necessary level of support to go forwards with it. -Splashtalk 23:38, 6 April 2006 (UTC)
There is general agreement that RFR cannot be implemented as-is, but isn't this entire discussion moot as there is a new proposal already? Titoxd(?!? - help us) 23:43, 6 April 2006 (UTC)
You mean in the section(s) below? Yes, it looks like something is being formulated gradually. But the project page doesn't appear to have been amended substantively, and I think (think) that this discussion originated on the question of whether that proposal is rejected or not. -Splashtalk 00:05, 7 April 2006 (UTC)
If you thought I was advocating passing the policy on the basis of the poll, you were mistaken. I apologise for the lack of clarity in my writing tonight - four hours sleep in 40! Sam Korn (smoddy) 23:46, 6 April 2006 (UTC)
Good $DEITY, go to bed! -Splashtalk 00:05, 7 April 2006 (UTC)
I agree, and while I was also one of the opposers, I think there's enough common threads amoung the opposers that some new formulation could be written that would swing a fair number of editors. There's some discussion along these lines above. Rx StrangeLove 21:26, 6 April 2006 (UTC)
I guess we're debating a moot point - after all, it's just a tag. :-) Even though I feel that it should be tagged as {{rejected}}, I don't mind if it's tagged with {{proposed}}. Thanks! Flcelloguy (A note?) 20:31, 7 April 2006 (UTC)

Reviving discussion

Well, since it appears that most of the problem is a lack of discussion, here's another idea, along the same lines as some of the opposing suggestions. Mav suggested that all editors who haven't been blocked for a determined period of time and have met certain criteria with respect to time and number of edits be allowed to have rollback. This proposal asks for editors who want rollback to ask for it. How about a hybrid? If an editor waits 3 months and has 1000 edits (or another arbitrary value), MediaWiki would set his permissions in the "rollback" group automatically, but if the editor doesn't wait, he can ask for it like in the old proposal. Also, if a user with rollback is blocked, his rollback button would be disabled, unless a bureaucrat reestiblishes his ability to rollback due to the block being unjustified or another reason of import. Thoughts? Titoxd(?!? - help us) 21:53, 6 April 2006 (UTC)

I think the automatic granting of roll back drew some pretty strong objections (though you set the bar high enough to maybe ease some of those concerns), I think that a simple list editors can add themselves to, letting the bureaucrats take it from there might work. It wouldn't involve a lot of bureaucracy, but there would be some control over it. There could be a page where violations are entered and bureaucrats could take them away if they felt it was appropriate to do so. Anyway....I think that might have a chance... Rx StrangeLove 22:06, 6 April 2006 (UTC)
I don't like the automation part (as Rx said), but the rest sounds to be a very sensible suggestion. Talrias (t | e | c) 22:08, 6 April 2006 (UTC)
The number should be high; rollback is oriented mostly for vandal-whackers, and regular editors who want it can just ask or write their name in a list at WP:RFR (no voting), like in the other proposal. However, automatic removal with blocks should take care of the violations. There were more complaints about too much bureaucracy than for automatic granting, and I'm one of the editors who opposed automatic granting the most; however, with some bureaucrat oversight, it should allay most fears. The problem with automatic granting is that it can be gamed, which is much harder to do when you have a human supervising the process. Titoxd(?!? - help us) 22:12, 6 April 2006 (UTC)

I think one of the things that might help allay the fears of the oppose voters is if rollback privileges are really easy to lose, i.e. if you use it for anything other than reverting vandalism, you lose it, and you'd have to re-apply to get it back. --Cyde Weys 23:25, 6 April 2006 (UTC)

That's always been part of the original proposal. Talrias (t | e | c) 23:26, 6 April 2006 (UTC)
Hmm... part of the problem is that some editors believe that rollback should not be restricted only for vandalism, as WP:AAP showed. That said, it was generally agreed that using it in a content dispute is a no-no, and part of the original proposal would change the blocking policy to allow blocks for misuse of rollback (as Bug 3801 is fixed now). This proposal would cause a block to disable the user's rollback bit while he is blocked and for a rather long period of time, unless the bit is reset by a bureaucrat. Titoxd(?!? - help us) 23:33, 6 April 2006 (UTC)
IMO, there is plenty of quick rollback script...hehe. True rollback is faster, but I think it best that only admins have it. The godmode that they have is a version of mine that does not have contribs rollback, only diff rollback, as it is easier to abuse that. I would rather see how people handle script, and then just let them be admins later on. Less seriously, remeber JS is fun...JS is your freind! How can I revert 2000+ edits with a few clicks? Sysop status + javascript....only useful against Willy though...Voice-of-AllT|@|ESP 19:17, 7 April 2006 (UTC)
Server-side rollback is superior and faster than Javascript. Also, it requires three page hits instead of only one, and is a much more powerful representation of a user's ability to use administrative tools. Titoxd(?!? - help us) 22:17, 22 April 2006 (UTC)

Interface

Without having to dredge through this page plus numerous other discussions about this; could someone tell me whether or not it is worth me going ahead and writing a possible interface to facilitate this? I'm prepared to start one soonish, before I hit the blocking mechanism, but I need to know if it's worth it; I don't want to waste my time if it's needless. Rob Church (talk) 01:07, 23 April 2006 (UTC)

I'd say go for the block interface first. There's still no consensus on the proposal. Titoxd(?!? - help us) 01:08, 23 April 2006 (UTC)
I would agree. This is not a priority right now, so if you have other things to do, do them instead. This may be used in the future, but consensus is not really for this right now. Thanks for your help though. --LV (Dark Mark) 01:13, 23 April 2006 (UTC)
I think there was enough consensus to give this a trial run to see if it'd work; but there's no way to move forward (or even try moving forward) until the interface is complete. —Locke Cole • t • c 21:03, 23 April 2006 (UTC)

An interface wouldn't take long to code, as I said; but as I also said, I don't want to put in the effort if there's no need. We now have the problem of interpreting consensus, and that's something I don't want to do, and shouldn't have to do. Two people state that it's not worth it; one person states it is. Rob Church (talk) 04:03, 24 April 2006 (UTC)

bureaucrat workload

I actually don't see why bureaucrat intervention should be needed to turn this flag on and off. It's low enough impact that absent arguments to the contrary, I think ordinary admins should be able to turn it on and off. Policy would stay about the same (privileges granted after request and brief discussion period, revocable (at least temporarily) on evidence of abuse, longer term revocation subject to discussion on WP:AN or elsewhere). That gets rid of the bureaucrat workload issue. Phr 01:12, 23 April 2006 (UTC)

Not necessarily. Bureaucrats are selected to handle user right promotions, so it would be more natural for them to do so; also, admins have a nasty tendency to wheel war, which would be highly undesirable for user promotions. Also, the "brief discussion" period is what has been considered the most unnecessary part of the proposal before. Titoxd(?!? - help us) 01:15, 23 April 2006 (UTC)
I don't think this is really a "promotion" since it doesn't create authority to do anything the user couldn't do already on the client side a little less conveniently. I'd put granting rollback as an admin function on a par with doing a speedy deletion, not with creating a new admin. I'd even be ok without the brief discussion (a notice posted somewhere by the admin would be enough), but in that case there'd have to be more policy against wheel warring (1RR then discussion). Generally a lot of RFA's that I consider marginal could be shifted over to this. Phr 01:21, 23 April 2006 (UTC)
Well, the current sentiment is to make granting the rollback flag much easier, even automatic; revoking in the short-term is easy, as a user cannot rolback while be blocked. However, that would make the revocation even more controversial; as a result, it should be carried by the most trusted members of the community, who are bureaucrats. Besides, there really isn't a bureaucrat workload issue; a bureaucrat has said that he doesn't mind doing rollback promotions, and there can always be more bureaucrats promoted. Titoxd(?!? - help us) 01:40, 23 April 2006 (UTC)
I share the widespread sentiment against promoting more bureaucrats unless really necessary, so I see anything that creates more work for them (and thus is likely to require more promotions) as suspect. The ideas of "automatic grant" and "need bureaucrat involvement" seem contradictory to me. Revocation should also not be a big deal, but if needed, that could be reserved for 'crats, since it would be less frequent. I don't think blocking users will usually be the right remedy for incorrect use of rollback since most of that incorrect use would probably be in good faith. So I'm imagining a process like speedy deletion, granted at first at admin discretion (based on reviewing user contributions) but subject to review and discussion on request of another user (DRV-like process). It occurs to me also that rollback operations can be logged and audited more easily than use of client side scripts, so getting more reverters using it instead of scripts is a good thing accountability and transparency-wise. Phr 02:01, 23 April 2006 (UTC)
Many users have previously said that they do not want admins to have promotion powers, at least when it comes to RFR; however, to make it easier, some users have proposed giving rollback to users who have not been blocked for a considerable period of time (at least half a year) and have had at least an arbitrary number of edits. I agree with you more in that I think revocation and granting rollback for users who fall outside the automatic requirements would be given to bureaucrats. Withing that automatic window, I don't think admins are even needed. Titoxd(?!? - help us) 19:26, 23 April 2006 (UTC)
But I don't see rollback as a promotion since it doesn't endow the user with any powers they don't already have. It's just a UI button that could be dangerous if misused, so I'm not keen on granting it automatically to all users. I'd be fine with automatic grant after N months with K edits in each month and no blocks, automatic 2-week revocation on any block, permanent revocation (restorable/resettable by admin, or by bureaucrat if you insist) after three 2-week revocations. Since admins are able to both impose and release permanent blocks on users, I think stuff like rollback should be well within their area of discretion, but it looks like that's just me. Phr 20:50, 23 April 2006 (UTC)
We select bureaucrats for their ability to decide bureaucratic things (like giving out sysop access; basically manning the janitor's closet and handing out mops). We select sysops/administrators because we trust them to use these tools, but we allow the bureaucrats to interpret consensus in the discussions. Similarly, I think we should defer to bureaucrats to hand out rollback (or maybe we should call it a "broom"). —Locke Cole • t • c 21:08, 23 April 2006 (UTC)
Yeah, I know, I'm not convincing anyone; but as I see it, the most fundamental tool available to users is the ability to edit, and admins can already turn that on and off by blocking. Turning rollback on and off is no big deal by comparison, since any user who can edit can already rollback, although maybe with 3 clicks instead of one. I don't have much more to add--I'm sure you folks will work out something reasonable one way or the other. I'd just like to see more users with rollback, since that means easier review (as described), fewer rfa's by RC reverters who mainly just want rollback, thus fewer admins and fewer wheel wars, etc. Phr 21:36, 23 April 2006 (UTC)
I agree with you in the fact that I would support an N/K implementation or similar, as well as utterly oppose any implementation that would give unrestricted access to rollback. The only thing that gives me pause in giving the power to grant rollback to admins is the tendency of 900 administrators to disagree and wheel war. Perhaps granting it would be an admin duty, but revoking it a bureaucrat duty? Titoxd(?!? - help us) 21:41, 23 April 2006 (UTC)
I like the idea of automatic revocation (at least temporary) on any admin block. Since rollback would be given out fairly casually, there likely would be cases of users going berserk with it (even in good faith) when there's no bureaucrat around. Another idea is dual control: require two admins to enable and/or revoke it, if you think one admin isn't enough. That would slow down wheel warring, and would be "bureaucratic" without getting actual bureaucrats involved ;-). Phr 03:17, 24 April 2006 (UTC)
Dual control is much more difficult to implement, from a developer's point of view; having a single user determine the status is already built into MediaWiki and can be adapted fairly easily. An admin block causing the rollback bit to be disabled is part of the proposal I outlined above, and if a user goes berserk with rollback, the user can wait behind a block for one of 20 bureaucrats to come. Titoxd(?!? - help us) 03:21, 24 April 2006 (UTC)
Dual control can't be that hard to implement--just have two rollback bits per user, don't let any admin set more than one of them, and require both bits set to enable rollback. I thought there were nowhere near 20 active en b'crats. And I'm concerned about keeping otherwise-good users blocked for long periods just because they screwed up with rollback. Better to disable rollback and let them keep editing normally. Phr 03:42, 24 April 2006 (UTC)
I agree with having rollback automatically disabled after a block, but I'm just not sure how that hard that would be to implement. Two bits may require a db schema change, but I'm not a developer... Titoxd(?!? - help us) 03:55, 24 April 2006 (UTC)
I hope that adding bits doesn't require a schema change, but if it does, that's maybe needed already, since right now rollback is reserved for admins, and this proposal is to separate rollback from adminship, thus adding a bit. Anyway, as Brion likes to say, policy shouldn't be designed around technical fine points. If implementing the right policy requires a little more code, then so be it. Phr 04:03, 24 April 2006 (UTC)
Rollback is already split from "sysop". See Wikipedia:User access levels (see also: m:Help:User rights). OTOH, making it possible for sysops to revoke rollback (but not grant it) is something that hasn't been done (and FWIW, I don't think should be done; bureaucrats can handle granting and revoking it (one of them even participated in the early drafting of this, IIRC, and indicated there'd be no issue with backlogs). —Locke Cole • t • c 05:14, 24 April 2006 (UTC)
Right now we're making 1 or 2 new admins per day; I'm imagining granting rollback (if it's done manually) maybe 10x that often, and at least 100x as often if it's done automatically. That's why I see noticable workload if B's are involved, especially if each grant requires even a cursory check of user history. Do those estimates (10x,100x) resemble yours? Phr 12:01, 24 April 2006 (UTC)
(belated reply) There might be an initial flood for the first few months, but I think it would slow down eventually and probably be equal to or less than the number of RFA's we have. —Locke Cole • t • c 03:24, 7 May 2006 (UTC)
  1. Rollback should not be given out on the basis of edit count. There are political and technical arguments against this. The technical side is that adding all users above a certain edit count to an implicit group would require at least one extra query on page view; this could turn into an unreasonable performance demand. There's a workable solution to this, however. On the political side of things; this is one of the wikis where "editcountitis" is discouraged and in some cases, condemned. An edit count is not a valuable indicator of a user's trustworthiness where rollback is concerned, nor is it a good indicator of the value and quality of their contributions.
  2. Administrators should not be able to give out rollback. This is because there is traditionally no high standard required prior to administrator promotion; it is given out in a liberal fashion. I would state that, in my opinion, it is not advisable to add this particular decision-making role to their responsibilities and powers. Our bureaucrats are promoted on the merit of their abilities to use their common sense and also gauge consensus; hence the reason I feel the task should be left to them.

I should point out that point #2 does not mean administrators should not be able to prevent users from using rollback. Indeed, a block on a user prevents rollback from being used, so an administrator can suspend a user's abuse of the tool if needed. Rob Church (talk) 19:55, 25 April 2006 (UTC)

Why do we need this?

There is code for your monobook.js to give you a rollback button, so what is the point of this proposal? ILovEPlankton 16:55, 2 May 2006 (UTC)

Read Wikipedia:Requests for rollback privileges again. Rob Church (talk) 21:45, 2 May 2006 (UTC)
To do it much faster, much more efficiently, and to help the servers a bit. Titoxd(?!? - help us) 22:08, 2 May 2006 (UTC)
Not all users use JavaScript, or even JavaScript-enabled browsers, and not all users who do use Monobook as a skin. Rob Church (talk) 13:16, 3 May 2006 (UTC)
But those who do already can have this button without any process of approval, if they can find it. Why would they apply? If they did, what would be the benefit to anyone in rejecting such users, given that if they have found the page, they probably already have it? If we agree that there is no point in rejecting a person with the right software, how could we then justify rejecting a person without the right software?
So I have to agree I don't get it. Why not give the rollback to anyone who can find it, which is how it is now for many, if not most, people anyway? Could it not be, for instance, a parameter to Special:Recentchanges (et al) but with no link to it? This parameter would then be documented at least on the RC Patrol page. This is something like the way the 'limit' parameter on that page is now: you can edit the URL to set it beyond 500, but there's no button to do it. -Dan 04:44, 6 May 2006 (UTC)

A script is not equivalent to rollback.

Well Rob, what matters to people who are concerned about abuse of the feature, and I hope they will forgive me if I put words in their mouths, is the ability to revert/rollback with one click, (or perhaps more to the point, without comment), and not any of the resource or reliability issues, nor even the distinction between the single last revision and all the last revisions by the same user. Therefore, from the perspective of possible abuse, yes they are equivalent. So, unless we are proposing somehow barring all the script versions, which I understand we are not, then I'm afraid I still don't get the point of the request-for-privileges process. Like the script, why not give it to anyone? Or at least anyone who can find it? -Dan 02:02, 7 May 2006 (UTC)~
There is one major difference: bot rollback. That cannot be done with the current scripts, that I know of, and if it is done, it is much, much slower than being able to click on a server-side rollback link. There's several situations where it can be disastrous to have someone with bot rollback go awry, so that's why there should be some sort of filtering. For this reason, it should emphatically not be given to just anyone. Titoxd(?!? - help us) 18:44, 10 May 2006 (UTC)

I don't see why you're arguing with me. I didn't bring the proposal. I'm just the developer who's likely to implement the changes needed to facilitate it. Rob Church (talk) 02:31, 7 May 2006 (UTC)

I thought you had also expressed an opinion on it that I disagreed with. This was my misreading, and my apologies to you. Cheers, -Dan 03:08, 7 May 2006 (UTC)

The only opinion I will acknowledge expressing is that the existing implementations using JavaScript are a little fragile, apparently breaking whenever the contributions page changes. Rob Church (talk) 16:29, 10 May 2006 (UTC)

What language are you planning to give the roll=back feature? If it explicitly said vandalism, that might answer some worries. !Septentrionalis 23:49, 10 May 2006 (UTC)
Well, I imagine the link would produce an edit summary such as MediaWiki:Revertpage, but part of the proposal defines unacceptable use of rollback (in edit disputes) which would trigger removal. Titoxd(?!? - help us) 23:54, 10 May 2006 (UTC)
It would be identical to whatever the existing wording is, because it would be the same code doing the work. Rob Church (talk) 19:12, 12 May 2006 (UTC)

Where do we stand?

Where are we at with this one? What objections are left to address? - Stephanie Daugherty (Triona) - Talk - Comment - 21:48, 8 August 2006 (UTC)

Bots

I have made a proposal to let some bots be granted this feature at Wikipedia:Village pump (policy)#Rollback to the bots!. Crossposting as this proposal is relevant to this proposal. Tizio, Caio, Sempronio 17:27, 7 November 2006 (UTC)