I understand the recent database indigestion was caused by someone deleting the sandbox on en:wp to get rid of a virus. It's times like these I wonder what happened to VoiceOfAll's individual revision deletion work ... is there any time frame on this? It's easier to oversight a single bad rev than it is to delete it, but much harder to undo if in error ...
- d.
On 16/01/2008, David Gerard dgerard@gmail.com wrote:
I understand the recent database indigestion was caused by someone deleting the sandbox on en:wp to get rid of a virus. It's times like these I wonder what happened to VoiceOfAll's individual revision deletion work ... is there any time frame on this? It's easier to oversight a single bad rev than it is to delete it, but much harder to undo if in error ...
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 1/16/08, Thomas Dalton thomas.dalton@gmail.com wrote:
How is this feature intended to work? Just being able to delete random revisions at will would mess up attribution.
The same is true for oversight. Obviously, don't delete revisions that will mess up attribution, or if you do, make sure the attribution is present in some other form. (This is perhaps an argument for storing revisions as diffs, but that was settled long ago.)
On 16/01/2008, Simetrical Simetrical+wikilist@gmail.com wrote:
On 1/16/08, Thomas Dalton thomas.dalton@gmail.com wrote:
How is this feature intended to work? Just being able to delete random revisions at will would mess up attribution.
The same is true for oversight. Obviously, don't delete revisions that will mess up attribution, or if you do, make sure the attribution is present in some other form. (This is perhaps an argument for storing revisions as diffs, but that was settled long ago.)
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.
On 1/16/08, Thomas Dalton thomas.dalton@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)?
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.
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.
Only if deletion of a single revision is not distinguished somehow in the database from deletion of an entire page. I don't know how this is handled in the current rev_deleted draft, you'd probably want to ask Aaron.
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.
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.)
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.
Only if deletion of a single revision is not distinguished somehow in the database from deletion of an entire page. I don't know how this is handled in the current rev_deleted draft, you'd probably want to ask Aaron.
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.
On 1/16/08, Thomas Dalton thomas.dalton@gmail.com wrote:
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.)
Well, yes. Nobody is saying oversight will go away, I don't think.
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
On 17/01/2008, Thomas Dalton thomas.dalton@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)?
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.
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.
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.
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.
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.
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.
A very good point. There's no way this feature can really make things worse...
On 1/17/08, Thomas Dalton thomas.dalton@gmail.com wrote:
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.
The basic security measure in a wiki is not to restrict access, but to allow problematic changes to be easily reversed. People seem to lose sight of this fact worryingly often these days. Of course it's not the *only* security measure, but it should always be the first resort, used exclusive of all other security measures unless in a particular case it specifically proves itself to be inadequate. I don't think admin deletion of revisions ever proved itself inadequate, except insofar as the current way to do it is extremely unwieldy.
So this completely defeats the entire principle that anything an admin does is easily reversible by another admin. Rogue admin deletes the Main Page? Better find an oversight user quick! Not a good idea.
On 17/01/2008, Simetrical Simetrical+wikilist@gmail.com wrote:
On 1/17/08, Thomas Dalton thomas.dalton@gmail.com wrote:
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.
The basic security measure in a wiki is not to restrict access, but to allow problematic changes to be easily reversed. People seem to lose sight of this fact worryingly often these days. Of course it's not the *only* security measure, but it should always be the first resort, used exclusive of all other security measures unless in a particular case it specifically proves itself to be inadequate. I don't think admin deletion of revisions ever proved itself inadequate, except insofar as the current way to do it is extremely unwieldy.
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.
So this completely defeats the entire principle that anything an admin does is easily reversible by another admin. Rogue admin deletes the Main Page? Better find an oversight user quick! Not a good idea.
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 1/17/08, Thomas Dalton thomas.dalton@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.
Well, yes. That doesn't have much of anything to do with the question of admin deletion, which is what this entire thread is about. They're different privileges.
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.
Of course it's for you to do, more or less, within Foundation mandate. Projects get to request changes to their settings in LocalSettings.php (within reason -- asking for all sysops to get oversight or checkuser isn't going to fly).
On 17/01/2008, Simetrical Simetrical+wikilist@gmail.com wrote:
On 1/17/08, Thomas Dalton thomas.dalton@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.
Well, yes. That doesn't have much of anything to do with the question of admin deletion, which is what this entire thread is about. They're different privileges.
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."
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.
Of course it's for you to do, more or less, within Foundation mandate. Projects get to request changes to their settings in LocalSettings.php (within reason -- asking for all sysops to get oversight or checkuser isn't going to fly).
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.
On 1/17/08, Thomas Dalton thomas.dalton@gmail.com wrote:
That was my point. You were the one suggesting they could be merged:
I don't actually think this thread of discussion is getting anything accomplished, since each of us seems to be persistently misunderstanding the other without making any kind of useful point. So I'll just say, and leave it at this, that what you quote was suggesting the *interfaces* could perhaps eventually be merged, *in response* to your explicit question about oversight, and said nothing about linking the features themselves.
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.
The people on wikitech-l (in particular, the developers and shell users on wikitech-l) are exactly the ones who decide things like this. wikitech-l is *meant* to discuss development issues like software defaults, and Wikimedia administration issues like site configuration policy. So I'm not sure what you're saying here.
The people on wikitech-l (in particular, the developers and shell users on wikitech-l) are exactly the ones who decide things like this. wikitech-l is *meant* to discuss development issues like software defaults, and Wikimedia administration issues like site configuration policy. So I'm not sure what you're saying here.
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.
--- Thomas Dalton thomas.dalton@gmail.com wrote:
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.
Why not? If rollback deleted all revisions by the last editor to the page instead of merely reverting them, page histories on popular articles might actually become usable again!
Zero chance of such a thing ever getting approval, of course, but it would work. :)
-Gurch
On 17/01/2008, Matthew Britton matthew.britton@btinternet.com wrote:
--- Thomas Dalton thomas.dalton@gmail.com wrote:
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.
Why not? If rollback deleted all revisions by the last editor to the page instead of merely reverting them, page histories on popular articles might actually become usable again!
Zero chance of such a thing ever getting approval, of course, but it would work. :)
Why not call it uber rollback? Simply because it will cause a reawakening of the current rollback controversy. Give it a different name and people will accept it without comment.
wikitech-l@lists.wikimedia.org