On 16/01/2008, David Gerard <dgerard(a)gmail.com> wrote: How is this feature intended to work? Just being able to delete random revisions at will would mess up attribution. Deleting only edits that were immediately reverted, or deleting all edits more recent than a given timestamp (basically an uber rollback, but whatever you do don't call it that!), would work.

On 16/01/2008, Simetrical <Simetrical+wikilist(a)gmail.com> wrote: Actually, what is the point of this feature? It seems it's just a milder form of oversight. In which case, wouldn't it be better to add a feature to oversight allowing different levels of oversight (similar to protection)? The issue of deleting large pages just needs a "delete last X revisions" button, which doesn't have any attribution issues. Deleting individual revisions has all kinds of other problems too (there is a discussion on wikien-l), for example if Admin A deletes one bad revision, Admin B then deletes the whole page and Admin C undeletes it, the bad revision comes back. Using oversight at different levels would prevent that while still giving the same desired functionality.

The big difference between oversight and deletion is who can do it and who can see the revision afterwards. Single revision deletion cannot replace oversight unless there is a way to stop regular admins seeing the deleted edit. (Such a way could be implemented, of course, I don't know if Aaron is intending to do so.) That would require a substantial change to the undeletion interface. That's not necessarily a bad thing, though. Knowing which deletion event deleted which revisions would be quite handy.

This quote answers some of the questions raised: "Oversight was created as a stop-gap, to deal with the high-priority cases for high-level revision removal due to privacy issues. If revision deletion bitfields go into full use later, there won't be a compatibility problem; we'll just stop using the old oversight system." -- Brion, December 2006, http://www.mediawiki.org/wiki/Talk:Bitfields_for_rev_deleted -- Yours cordially, Jesse Martin (Pathoschild)

On 17/01/2008, Thomas Dalton <thomas.dalton(a)gmail.com> wrote: Possibly. The point is that (a) admins will often see individual revs they want to zap (prior to notifying the oversighters, usually - but take them out of public view ASAP) (b) it needs to be easily undoable in case of error (c) it needs not to have the effect deleting a page with a zillion revs does. Making the oversighters more of a bottleneck is the problem I see there. Giving admins the power to delete individual revs wouldn't IMO be a great change from now - they currently do it, they just have to do it by deleting the page and selectively restoring all except the bad revs ... which seems to me more prone to error. - d.

It could be done so admins can delete revisions in such a way that only oversighters can undelete them. That would solve (a) while failing (b). Allow admins to undo only their own such deletions would help. This would, of course, be in addition to deleting revisions in such a way that any admin can undelete them. A very good point. There's no way this feature can really make things worse...

On 17/01/2008, Simetrical <Simetrical+wikilist(a)gmail.com> wrote: Oversight is used in cases where information needs to be removed from sight, including the sight of admins, deleting revisions doesn't achieve that. That's why we have oversight. Of course, that's why we like all actions to be reversible. Deciding who can do what isn't really for us to do - it should be a setting in LocalSettings.php.

On 17/01/2008, Simetrical <Simetrical+wikilist(a)gmail.com> wrote: That was my point. You were the one suggesting they could be merged: "Oversight is not in the core software, to start with. This is. Your question could be rephrased: why doesn't oversight use the built-in deletion interface? Maybe sometime it will, once there *is* a built-in deletion interface for single revisions. Probably it would be nicer, once rev_deleted is in, to just have a checkbox on the "delete revision" page for those with the appropriate privileges. Essentially, you're asking about interface/naming details. It's the same feature either way." I meant "us" as in "the people on wikitech-l". It's important not to forget non-wikimedia wikis that use Mediawiki as well - they're needs are often very different in matters of security.

I think we're talking about a different "this". Developers decide what features to implement and how to implement them, but they don't decide who to give each permission to. One site might want only a select few to be able to use oversight, another might give it to all admins and yet another might want to let any admin oversight something but only a select few un-oversight it again - all of those options should be supported by the software, so discussion about which one is best is completely off-topic for this list.