Last modified: 2011-02-08 21:56:33 UTC
A policy has been drafted ([[Wikipedia:Revision_deletion]]) and subsequently accepted ([[Wikipedia_talk:Revision_deletion#Community_consultation]]) on the English Wikipedia regarding the use of RevDelete by administrators. Such a policy existing and being accepted (after a large and lengthy discussion) is evidence of a community consensus regarding the right being enabled on our project. Please add $wgGroupPermissions['sysop']['deleterevision'] = true; to the relevant configuration file on the Wikimedia servers. Thanks, fl
Why should enwiki separate itself from all other projects ([[bugzilla:18780]])? RevisionDelete was not enabled on dewiki either ([[bugzilla:19697]]) although it has been accepted that feature.
(In reply to comment #1) > Why should enwiki separate itself from all other projects ([[bugzilla:18780]])? > RevisionDelete was not enabled on dewiki either ([[bugzilla:19697]]) although > it has been accepted that feature. > Perhaps because people are still wary about enabling it globally but on en.wiki (and de.wiki as you point out), local consensus is in favour of granting it to admins.
See bug 18780 comment #12
FT2's comments notwithstanding, there is community consensus for this to be enabled. Moreoever, oversighters are using revision deletion on a regular basis and these actions cannot be scrutinized by the regular admin corps until this feature is enabled.
The tool needs to be "fit for purpose" before doing so. Its purpose includes tracking and easy review of deleted revisions and scrutiny of the actions admins may undertake... which at present it can't provide. Complaining there is consensus to enable a fully usable RevDelete that allows admins to scrutinize and review each others actions, when log entry link mechanisms break, is going to lead to some interesting effects. Try figuring the history of a dispute when the log tells you 2 revisions were redacted but cannot tell you which of the many possible candidates were the two being deleted or restored and who did what in which order. It was tough enough for 20 active oversighters on the occasions when they had to track unfollowable links in the logs. There are _2000_ admins who will be trying to use this tool and it will be enwiki's main (and almost exclusive) deletion tool for anything except full page deletes, once enabled. Virtually every single revision delete, undelete, redact, unredact, and delete review/scrutiny action on the entirety of enwiki? 2000 admins? Widespread log link breakage? Let's request the developers fix it first. On your second point, apologies, you're mistaken. Admins have had view-only access to RevisionDelete for many months now (when not in Suppression mode for Oversight purposes). Admins can and do have access to scrutinize all non-oversight use of RevisionDelete as they wish. They have had this for a very long time.
I disagree. The last thing I'm worried about is log link breakage, hell if that's our biggest problem, then we need to enable this now. The way the current deletion system works is not in anyway remotely helpful. Take the Child Pornography article for example. Right now there are 349 deleted revisions on that page, if someone else drops by and decides to leave behind something that should be deleted on sight, you have to delete the whole page... and then search for each and every edit that you had deleted previously. This is a problem, this is the *real* problem. To another of your points: You continue to cite the amount of admins on enwiki as "2,000"... that is far from accurate. Not only is the current amount of admins with accounts... nearly 300 less than that. The amount of actual active admins is only 824. I highly doubt that it would be that much of a catastrophe if a few log links get broken in the rare occasion of an undelete after a delete.
If someone leaves something of that kind, you ask an oversighter to use RevDelete, and that action (and the redacted material) is visible to all admins to scrutinize. Having tools that don't allow a practical means of scrutiny (which is how bad this can be) means uncheckable deletion logs. Whether this involves 864 admins or 1700 is almost immaterial, it's a problem whichever the number is. These are not edits that are a "bit annoying" to review. They are deletions and log deletions that literally, cannot be checked. You can't always tell what was deleted. You can't always tell who deleted or undeleted it. If there is a dispute, an ANI/RFC/RFAR case, or a request for review of an admin action, you might not be able to review it. And some number between 800 and 1700 admins will be using it hundreds or thousands of times daily. (Details: Bug 18780 comment 12). It needs this part to work. If you have a case come up needing specific revisions redacting, for now ask an oversighter. This bug's been known since March 2009 or earlier. A range of fixes been proposed (eg see bug 21279). When a fix is coded we'll have an admin-usable RevDelete system. Aaron states (bug 21279 comment 7) he may have something that will fix it. Hopefully he can make it work.
(In reply to comment #4) > FT2's comments notwithstanding, there is community consensus for this to be > enabled. > > Moreoever, oversighters are using revision deletion on a regular basis and > these actions cannot be scrutinized by the regular admin corps until this > feature is enabled. Confirming that per FT2 I am mistaken above and now have seen the light (or more specifically the prompting that "As an administrator you can still view this diff if you wish to proceed." That being said, the fix to the problems FT2 highlights should be prioritized and this should be rolled out ASAP.
FT2, I see what you're saying. But I still don't see this happening as frequently as you are insinuating. Also it would be necessary for an admin to have done something against policy for them to need to undelete it in the first place... that amazingly enough doesn't happen every day. So with 864 admins, using RevDelete, and one every once in a while screwing up a revdelete... I just don't see the big issue. This has been on the back burner for a while, and while I understand the devs have other things to do, this does need to be high priority, I would even say right up there with FlaggedRevs.
Please remember Bugzilla comments is for technical discussions relating to the bug report, Other discussions should be taken else where.
Please enable this. The ability for administrators to quickly and efficiently remove sensitive or dangerous content without having to email oversight or use a wonky delete/restore selected revisions should trump the concern of not being able to link efficiently to the log action.
This one seems to be enabled now. It must have happened between today and 4 days ago. http://noc.wikimedia.org/conf/InitialiseSettings.php.txt 'groupOverrides2' => array( 'default' => array( 'sysop' => array( 'deleterevision' => true,
Sometime in the last half hour
OK. Good :-)
Unfortunately the bug was not fixed. There is a discussion that's still open with consensus leaning towards "not yet". http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Proposal_to_turn_on_revision_deletion_immediately_.28despite_some_lingering_concerns.29 The bugzilla actions and notes are: * This bug and bug 18780 were closed on the basis "function seems to have been enabled" * The underlying bug 21279 was re-prioritized as "critical" and another user asked "RevisionDelete was enabled now; what will happen with that urgent bug request" With respect, this is a request to disable the function due to the known problems and leaning consensus to "not yet until fixed". RevDelete's log link failure issue was a problem with limited use and a couple of dozen oversighters. Enabling it for 500 - 900 active admins and widespread use doesn't compute. Two efforts are underway to fix it - Chruch of emacs via RevisionMove and Aaron via some code he has said he's "dusting off". Please consider re-disabling the function until this critical bug/issue has a fix and there is communal consensus to enable.
This was done, and not rolled back. bug 21279 remains open, but it can be tracked separately.
