Last modified: 2014-01-23 19:19:55 UTC
At present we now have 4 means of deleting material from either the public or from administrators. Material can either be * Deleted from the public with traditional deletion * Deleted from the public (part or full) with RevisionDeleted * Deleted from admin view with Oversight * Suppressed from admin view with RevisionDeleted This collection means that any review of editor actions or conduct, or article matters on the wiki, now faces two big problems in evaluating the existance or seriousness or any issue: * It's incredibly easy to overlook some edits or actions in the review, which should be taken account of. * It's more complex and takes examination of several screens, to review a matter. * Each of these has different mechanisms for viewing edits they affect; there is no consistency of links, formats, access methods, etc. * A third issue at a technical level - it's a lot to maintain, and allows for inconsistent software behavior (or bugs fixed in one of these but not spotted in the other), and requires more developer time etc. I would like to suggest that in fact, all we now need is RevisionDeleted, with the following options: * What to hide - revision text, edit summary, user name/IP * Whether admins can or can't access the hidden data * Whether admins or users who cannot access the hidden data, should nonetheless be able to see it exists even if they can't read it (there are cases when this is safe, and cases when it isn't). This proposal is that RevisionDeleted is amended slightly to show the above options, and then both traditional deleted revisions and oversighted revisions are converted to RevisionDeleted entries as a background task (ie a script written that achieves this in the job queue over time). Following this: * Delete and oversight both redirect to RevDel for their actions * Delete/undelete and oversight url's both redirect to the appropriate lookup link for any historical URL used to view an old deleted/oversighted edit. The issue here is not so much one of software development, as of a once-off conversion task of old data stored in one system to be moved to another.
(2, 3, 4, ... I can't count!)
(Note - this may be agreeable but not practical until admin use of RevDel is enabled, and any significant issues from the rollout of RevDel are addressed)
See bug 17444.
Would it be sensible to set this bug up as a tracking bug? Its general principle (phase out other forms of oversight in favour of a tweaked-up RevDel) is blocked by most of the other bugs out there. We certainly need *a* tracker for all this stuff; while compartmentalisation is good, we have a lot of plates spinning at the moment.
(In reply to comment #4) > Would it be sensible to set this bug up as a tracking bug? Its general > principle (phase out other forms of oversight in favour of a tweaked-up RevDel) > is blocked by most of the other bugs out there. We certainly need *a* tracker > for all this stuff; while compartmentalisation is good, we have a lot of plates > spinning at the moment. > I've sort-of done that by shifting the depends to blocks on bug 18598.
See also bug 20290, covering a "hide placeholder" option in RevDel. Added the dependency.
It's really about time to remove the Oversight extension entirely; that's under discussion. That would leave only 3 deletion options, which are really 2 (admin deletion and RevDel with optional suppression).
