Last modified: 2014-11-03 08:44:53 UTC
Currently, revision deletions are logged in the deletion log, and thus they are completely lost. A specific log for them, maybe Special:Log/hide, would alleviate the concerns of transparency and admins could review each other's actions if/when the feature is enabled for admins.
Once RevDel is available to admins, no special log will be needed since any admin will be able to view (or review), ordinary redaction, if they want to. At most this would therefore be a transitory measure, not worth amending the interface for. What would be useful would be a toolserver tool to list the RevDel items in the deletion log, for use until such a time as admins can view them "natively" through MediaWiki. But thats a separate matter.
I agree with Cenarium here. Deleting a page has effects other than the appearance in the deletion log -- red links appear, diff links fail to work, etc. RevisionDelete, on the other hand, is far more silent -- you can only tell the action has been taken by viewing the individual revision or by viewing the log. Therefore the log is far more important for transparency and prevention of abuse. These (important) functions would be helped by a separate log, as normal deletions are of such volume that revision deletions will be swamped.
But removal of data (by any means) is only ever a problem if something is hidden that shouldn't have been hidden, and something is only "hidden" (in this sense) at a point where a user would have seen it but for the action taken. (ie, a redaction of (say) an edit summary that nobody has ever looked at anyway isn't making any difference; it's a potential problem only at the point someone looks at the record and /would/ have seen it but now cannot/will not.) With RevDel, at that point the user can always (without fail) know that material has been hidden and any user who should be able to check it was correctly hidden, can do so.
Additional observation -- The logic you're suggesting also has a major flaw. It's fine for full page deletion. But the delete log also has revision deletion by normal admin delete (full delete + restore "all but N" revisions). Those are far more "silent", create no redlinks, etc, and yet no "separate log" has ever been suggested as essential for those.
FT2 is arguing that oversight of the use of this tool should be entirely reactive. I disagree -- it should be possible to perform proactive oversight. The argument about deletion-selective undeletion is, I think, somewhat specious. It would have been impossible to log those events without a new functionality that does the whole action at once -- which is what RevisionDelete is. The need for the delete-undelete method has been obviated by the superior RevisionDelete system; my argument is that that system can be further improved by the provision of a separate log. I don't see any benefits of the combined log; there are significant benefits to a separate log.
The main disadvantage of multiple logs is that you then have to search in multiple places to track down what's gone on in any matter, as multiple tools may have been used or have interacted. The essence of the logs is to allow traceability for users patrolling them. Too many logs or tools all running in parallel defeats that purpose. I don't have a problem with separate logs per se. Rather, I would like to know that when an admin or oversighter looks at a matter they can see all kinds of "deletions" affecting a page in one place, not split up over a growing number of separate logs. The prolific spread of features and logs is a good thing, but logging of actions is one of those things that should be as much rationalized as possible. Deletions should not be spread over that many logs unless there is /also/ some way to quickly check all those logs at one go. Without that ability, creating an extra delete log for a matter that is (when all said) visible and easily checkable if any user anywhere has any query, can bring more time loss and inefficiency than it brings benefit. One solution might be to allow [[Special:Log]] to have categories in its dropdown list: ALL BLOCK LOGS Global block log Local block log ALL DELETE LOGS Delete log RevDeleted log Suppression log ALL USER ACCOUNT LOGS User creation log User rename log User rights change logs etc That would solve the issue nicely. But I don't know how technically feasible it is.
Actually - proposed that. It's got potential to help. See bug 18836.
A separation of the logs is justified from a technical point of view, as those actions are of a completely different kind. It is justified for analysis and statistics purposes, and as said above, for transparency and abuse prevention. Considering the amount of controversy (past and still present) surrounding the use of oversight-like tools, it is even more justified. Furthermore, preliminary discussions on the new tool, see [[Wikipedia talk:Selective deletion]], indicate this is a big issue for the community in enabling this for admins. Log proliferation is not an issue in this case. First, I do not see why a person would like to see both the deletion log and hide log (and it is my understanding that the suppress log is already separated), but not each one separately, while the inverse is certainly true. An other log won't be a problem for a specific page, as there's a few of them in most cases, all accessible in the main log, and a more precise filtering shouldn't create any problem. And globally, it would be a problem only if the logs were of the same nature, which is not the case. As for visibility, of course if an admin hides a summary on ANI, it will be highly visible, but there are plenty of pages were this will not be so visible and abuse - or mistakes - may take place. And again, log entries can also be hidden, and their visibility is generally much lesser, as it doesn't show up in histories or watchlists.
(In reply to comment #8) > As for visibility, of course if an admin hides a summary on ANI, it will be > highly visible, but there are plenty of pages were this will not be so visible > and abuse - or mistakes - may take place. And again, log entries can also be > hidden, and their visibility is generally much lesser, as it doesn't show up in > histories or watchlists. > Deletion of one revision, multiple revisions, or all of them are all deletion, and are logged in the deletion log. Why wouldn't that be shown in the watchlist? Why is the deletion log not a visible enough place to log deletions?
(In reply to comment #8 also): > And again, log entries can also be hidden, Not correct in terms of overall effect. Log entries cannot be hidden without an entry in the suppression (oversight) log. The text of a log entry can be hidden, but the entry itself /cannot/ -- an entry with hidden text will either be oversighted (own log) or trivially visible to any admin who is interested or wants to check. > and their visibility is generally much lesser, as it doesn't show up > in histories or watchlists. Incorrect, the entry ahows up in /all/ histories and watchlists, the /only/ difference is some parts may be marked "deleted" -- but /any/ admin can trivially view and check these.
(In reply to comment #9) When mentioning the watchlist, I considered hidden log entries (not edits). If you hide an entry in the user creation log, it won't show up in your watchlist (AFAIK, you can't watch the user creation log). And it's also the case for the move log, protection log, etc, even if there is a target, it doesn't show up in your watchlist (while actions to hide revisions are shown). Again, revision visibility is not the same as deletion, the effect is completely different (see comment #2). Those entries would be lost in the deletion log and largely inaccessible, thereby decreasing the transparency and abuse prevention potential, and so reducing usability and chances for the software to be enabled for admins on enwiki. Maybe it wouldn't be a big problem on wikis with low activity, but on enwiki where we have on average half a dozen deletions by minute, with peaks at several dozens by minute, it's impractical. (In reply to comment #10) We can hide the following for logs: log summary, and/or username, and/or action and target. They can also be hidden by admins when enabled, at least in the config on testwiki. Again, I was speaking of hidden log entries, that don't show up in watchlists or histories, not edits. An admin can check hidden content only when it is aware of it, if those actions are lost in the deletion log, the check won't be possible. Given the controversial nature of this, we can't afford a "don't bother until a problem is finally found" attitude.
Internally, you have log_type and log_action. Currently, most log views are separated by log_type, not log_action. For example, log_action="block" and log_action="unblock" are both in the log_type="block" category. Same with deletions (you'll notice how undeletions and deletions are in the same place; the same is true for protections / unprotections). It may be a better idea to start splitting by log_action rather than log_type, if possible. Perhaps not by default, but the option should be there in the interface.
(In reply to comment #11) > (In reply to comment #9) > > When mentioning the watchlist, I considered hidden log entries (not edits). If > you hide an entry in the user creation log, it won't show up in your watchlist > (AFAIK, you can't watch the user creation log). And it's also the case for the > move log, protection log, etc, even if there is a target, it doesn't show up in > your watchlist (while actions to hide revisions are shown). Sure, so perhaps the watchlist should list when the log entry for an action affecting a watched page is changed (hidden/unhidden/whatever). I think that should be done, actually - I'll file a new bug shortly. > Again, revision visibility is not the same as deletion, the effect is > completely different (see comment #2). I understand how it is different... > Those entries would be lost in the > deletion log and largely inaccessible, thereby decreasing the transparency ..but I don't understand how these log entries would be "lost" or "inaccessible" or not transparent. For pages, it states clearly what page was affected. For logs, it states what log was affected, but it doesn't state clearly what that log entry was about (in some cases it can't, since that's what was hidden). I'm still trying to think through how to make this more readily intelligible to the user, as it's really not satisfactory right now, IMO; please see bug 18335.
(In reply to comment #12) > Internally, you have log_type and log_action. Currently, most log views are > separated by log_type, not log_action. For example, log_action="block" and > log_action="unblock" are both in the log_type="block" category. Same with > deletions (you'll notice how undeletions and deletions are in the same place; > the same is true for protections / unprotections). Apparently, there's a log_type 'suppress', but no log_type 'hide'. So hide actions are recorded as deletions, well, since we have a log_type for suppress, I suppose we could have one for 'hide' too. It would allow to have a separate log. > It may be a better idea to start splitting by log_action rather than log_type, > if possible. Perhaps not by default, but the option should be there in the > interface. Being able to filter a log by log_action would be interesting indeed, to have a list of undeletions for example (so a better control of 'selective deletions'). (In reply to comment #13) > Sure, so perhaps the watchlist should list when the log entry for an action > affecting a watched page is changed (hidden/unhidden/whatever). I think that > should be done, actually - I'll file a new bug shortly. I agree, that would be an improvement. But there are still logs with no target, and plenty of pages that are not heavily watched. > ..but I don't understand how these log entries would be "lost" or > "inaccessible" or not transparent. For pages, it states clearly what page was > affected. For logs, it states what log was affected, but it doesn't state > clearly what that log entry was about (in some cases it can't, since that's > what was hidden). I'm still trying to think through how to make this more > readily intelligible to the user, as it's really not satisfactory right now, > IMO; please see bug 18335. The issue is that the use of oversight-like tools has become quite controversial on enwiki, so users want to be able to see all those actions recorded in one place to be able to challenge them, review them one by one if they're sysop. If they are hosted in the deletion log, for 1 of those actions, there would be maybe 1000 deletions, they would be lost among deletions. So you couldn't find them easily, or you'd have to extract them specifically, which would be a pain and not live.
(In reply to comment #14) > I agree, that would be an improvement. But there are still logs with no target, > and plenty of pages that are not heavily watched. See bug 18866. > The issue is that the use of oversight-like tools has become quite > controversial on enwiki, so users want to be able to see all those actions > recorded in one place to be able to challenge them, review them one by one if > they're sysop. If they are hosted in the deletion log, for 1 of those actions, > there would be maybe 1000 deletions, they would be lost among deletions. So you > couldn't find them easily, or you'd have to extract them specifically, which > would be a pain and not live. OK, but then why are you not also concerned about losing one of the normal deletions in the deletion log? It would be "hidden" by 999 other normal deletions, which isn't so different from being hidden by 1000 normal deletions plus 1 "hiding". This sounds to me like you don't trust your sysops. That is not a technical issue which should be reported to bugzilla, or which can be fixed in the source code.
Many deletions are automatic, and the vast majority of them are not checked. We generally trust our sysops, but we should still consider potential mistake and abuse when implementing a new functionality. The fact this topic has been surrounded by controversy makes it even more needed. Yet, this is not the primary reason justifying a separate log, but simply because those actions are not of the same type, and sufficiently different technically and in use. One will generally want to check 'page deletions' and not 'revision deletions', or vice-versa. Not having the differentiation would be more time consuming due to the volume of operations. Incidentally, I don't see what negative effects this could have. We have four quasi-unused log types on enwiki (merge, import, global rights and global account), and this is not seen as a big problem. But this one would be much more used.
Now I know that this doesn't "fix" the bug, per se, as it isn't in the MW codebase, but may I draw people's attention to http://toolserver.org/~fl/revdelete/ This is a tool (in active development, but fairly stable for most tasks) that I wrote that filters the English Wikipedia's deletion log to only show revision deletion actions. It allows searches by title, user who performed the action and date (although the date functions are currently a bit messed up at the moment). It also allows you to further filter the logs to only event hiding actions or only revision hiding actions. Hope that helps.
All deletions are logged in...the deletion log :) A filter might be a good idea though, given the revisiondelete items have there own log_action.
(In reply to comment #18) > A filter might be a good idea though, given the revisiondelete items have there > own log_action. Bug 20839 has been created and then closed as duplicate of bug 18954.
(In reply to comment #18) > All deletions are logged in...the deletion log :) ... is not an acceptable reason to WONTFIX a request to address a clear usability issue. Duping to bug 24932, to make it easier to find this old discussion. *** This bug has been marked as a duplicate of bug 24932 ***
This is the original bug.
*** Bug 24932 has been marked as a duplicate of this bug. ***
Changing summary from "log" to "log_action". Propose to implement filter via bug 18954. Tracking similar requests via bug 28412.
18 months with no progress. Is there anything in particular blocking this?
(In reply to Rd232 from comment #24) > 18 months with no progress. Is there anything in particular blocking this? Not that I knew. Patches in Gerrit are welcome.
