Requests for comment/Global file deletion review 2

Dialog-information on.svgThis is a subpage; for more information, see the Requests for comments page.

Statement of the issueEdit

Previous RfC: Requests for comment/Global file deletion review

In late 2014, an RfC related to Global deleted image review was proposed. This proposal intends to create a new global group, designed (but not limited) for sysop at Wikimedia Commons, which enables a user to view deleted files and corresponding description pages globally. This proposal was closed as "successful" but for some unknown reason, there was no further implementation after that. Then, seven years later, I found this historical RfC, then start a relevant discussion on Pub (permalink). From this discussion, there are still some users interested in this proposal. As seven years could change a lot of things, I think a new RfC is needed for the implementation of this group. — The preceding unsigned comment was added by Stang (talk) 19:06, 31 March 2022 (UTC)

Update on 2022-05-06Edit

For technical issue, it is impossible for user to view deleted revision and files with only viewdeletedfile permission applied - user will find they could not open Special:Undelete. The simplest solution is append deletedhistory permission to global group GFDR. A sample group has been created on Beta Cluster, anyone willing to test could contact local steward or local global developer, and they could found deleted files somewhere like here.

Something not that ideal would be:

  • GFDR user could see deleted history of any pages; however, that could only see something like action=history, and could not see the content of any pages.
  • GFDR user have access to Special:DeletedContributions (example); similarly, they have no access to content of revisions.

This issue makes GFDR group quite dangerous, as they could acquire many information out of the scope of this group. Because of this, I extend the waiting days when applying in implementation section to 14 days (same as GS).

Another point was raised by @whym that this group should not be given infinitively as it could access many sensitive or privacy-related information. I found a similar group on English Wikipedia called researcher, which needs the approval from WMF. This group seems to have a confirmation process (every two years?) Based on this precedent, I think it is necessary to add a confirmation process every two years, and GFDR user would be appointed temporary only.

Above are updates on 2022-05-06. Stang 14:36, 6 May 2022 (UTC)


From previous RfC, should have some necessary modifications. Feel free to edit this section.
  • Q: What's the name of this group?
    • A: Global file deletion reviewers (global-file-deletion-reviewer), has an abbreviation called GFDR.
  • Q: What permission are included in this group?
    • A: viewdeletedfile and deletedhistory permissions.
  • Q: Automatically approval for Commons Admin?
    • A: No. Candidate must request this permission at SRGP manually, steward will grant/decline per community consensus after at least 14 days after request is posted.
  • Q: Who can request for this group?
    • A: Commons Admins and VRT permission agents, or someone else with a valid reason.
  • Q: WikiSet scope?
    • A: A new wikiset will be created to allow site to be opted-out (as some large wikis would be not that happy to this group). Notification will be send to VP on large sites once consensus of the creation of this group is reached.
  • Q: Removal?
    • A: If user no longer holds privileged permission or VRT access, no edit among all project for one year or abuse/misuse of this permission.
  • Q: Expiry?
    • A: GFDR user need to confirm every two years, they could open an renewal request at SRGP before the expiry.


  •   Support. -- Jeff G. ツ (please ping or talk to me) 15:09, 2 April 2022 (UTC)
  •   Support After witnessing MGA73 and his wonderful work of deleting and importing (to Commons) old files crosswiki, especially at small wikis, I believe GFDR is needed (and I'd give MGA a   Support if he ever wants this tool). NguoiDungKhongDinhDanh 23:52, 3 April 2022 (UTC)
    (thanks to Dmehus) Addendum: ...on condition that GFDR will only be removed due to inactivity, resignation or abuse. Since users must apply for this flag at SRGP, that their privileged permission[s] somewhere else being revoked is irrelevant. NguoiDungKhongDinhDanh 02:42, 16 April 2022 (UTC)
  •   Support --Minorax«¦talk¦» 01:17, 4 April 2022 (UTC)
  •   Support It is a big help if admins on Commons can see deleted files on the original source. It will of course also be helpful if admins can undelete the file, retransfer to Commons and delete again but that would probably need a different Rfc.
I often need to see deleted files on enwiki and usually I bug User:Magog the Ogre to check the deleted file but not all wikis have users that respond fast so it can be a pain to keep track of requests. --MGA73 (talk) 14:10, 4 April 2022 (UTC)
  •   Support Why not? A very useful process. --Liuxinyu970226 (talk) 04:14, 8 April 2022 (UTC)
  •   Support --MdsShakil (talk) 18:24, 9 April 2022 (UTC)
  •   Support. Wikiarchaeologist vibe! —— Eric LiuTalk 08:55, 10 April 2022 (UTC)
  • I agree that there is valid need. I am concerned with how we can monitor inactivity and prevent unnoticed misuse with passive rights like this, not just because people can be malicious but accounts can be compromised. In the absence of logging, one possible safeguard might be making the rights expire after a period, like 1 or 2 years, with possibility of extension upon request. I'd be reluctant to have someone permanently hold the rights unless there is a very good reason to do so. (Again, it will be okay for me if there will be logs, perhaps not public, but still continually visible from some users like fellow global deletion review users and stewards, for example.) whym (talk) 11:35, 12 April 2022 (UTC)
      Support with the confirmation requirement added later after the discussion below. I reiterate that I suggested this as a remedy to the lack of logging. As far as I'm concerned, the requirement can be dropped when the software records individual users' use of the GFDR rights somehow and allows others to review. whym (talk) 12:53, 9 May 2022 (UTC)
  •   Support Should be granted all Commons admin automatically, not sure what is the added value of admin approval. Jklamo (talk) 08:43, 14 April 2022 (UTC)
  •   Question: I don't really have any issues with this, or with the indefinite nature of this new global permission, but can we clarify what is a "privileged" permission? If it's defined as sysop or above on any wiki, I'd be opposed. If it's defined as patroller, rollbacker, or anything above autopatrolled on any wiki, I'd be inclined to support. Stang, can you provide that clarification before I give my support or opposition argument? Dmehus (talk) 02:29, 16 April 2022 (UTC)
    • @Dmehus: the "privileged" permission is brought from "Advanced right holder" on this page, which means a permission require community's approval (rather than approval from only one admin). As viewing deleted content is part of the admin toolkit, it is reasonable for candidate to be an admin or pass a process similar to RfA.
      Stang, thanks for the clarification. I suppose that's reasonable. For the sake of clarity, would a bot approval request on a local wiki satisfy the requirement to being functionally akin to an RfA (since those typically require a community election, or at least a community discussion)? Basically, you're just looking for anything requiring a community election, whether local or global. So it could be a global-renamer, global-rollbacker, etc., but not, say, patroller, rollbacker (unless a wiki requires rollbackers to be elected, of course), or OmbudsCom? Dmehus (talk) 23:14, 16 April 2022 (UTC)
      Dmehus, I have removed the statement contains word "privileged" above, but I am happy to response the question you raised. Yes, I am looking for a "community election", but such election must at least has some connection with this proposed permission group - "Global file deletion reviewer", and all example in your question is irrelevant to it. Stang 22:51, 20 April 2022 (UTC)
    • @Jklamo: seems there were some concerns of automatically assign this permission per pervious RfC (if I understand correctly, concerns were raised after this issue, one of the parties who get their permission revoked was an Commons administrator). I just don't think an extra consensus gathering on meta is a big problem.
    • @NguoiDungKhongDinhDanh: this point sounds reasonable, what do you think of the definition of inactivity, one year without edit among all project?
    • @Whym: Supervision is nice, but this do need a lot of code work, so maybe unlikely to be implemented for a short time. Stang 12:36, 16 April 2022 (UTC)
      Sounds good to me. NguoiDungKhongDinhDanh 18:17, 16 April 2022 (UTC)
      I still think it's wise to have the permission granted with an expiry period, considering the wide scope and the passive nature of the permission, if logging is not possible at the moment. To be more concrete, I'm thinking of something like: "As a general rule, this permission is granted for 2 years or shorter. It can be extended after a successful request at SRGP. (This rule may be revised later.)" How does this sound? whym (talk) 11:54, 17 April 2022 (UTC)
      Nice point, Whym. The only three global groups requested on SRGP page which require an expiry period (GIE, AFM and Global deleter) all hold permission which could change the setting or content on a project, and I believe this is the main reason why they must be renew every (two) year(s). This global group I thought is more similar to AFH - read only, so IMO an expiry period is not necessarily needed. (BTW this is also the reason I set the minimum waiting period to 5 days - if you thought this is not long enough, just raise your suggestion). Stang 22:51, 20 April 2022 (UTC)
      AFH can be a good reference point. Viewing of deleted files and associated edit histories might involve data privacy of regular contributors among other content hidden from the public, and it can extend to data contributed years ago. Viewing of hidden abuse-filters and associated logs concerns non-deleted content in general and its scope goes back as far as RecentChanges allows you to see (at least I believe so). Perhaps an apple to orange comparison due to the qualitative differences, but at least GFDR's data volume seems larger and that's one reason for me to ask for more scrutiny. I wouldn't want to have somebody hold the rights for 10+ years while nobody can verify whether they have used the rights or not. Since my concern is more about long-term scrutiny, I don't particularly want to make the initial waiting period longer. whym (talk) 13:16, 24 April 2022 (UTC)
      This is a good point, I made some changes to the implementation section. Stang 14:36, 6 May 2022 (UTC)
  •   Support per above. --SHB2000 (talk | contribs) 07:11, 17 April 2022 (UTC)
@Jeff G., NguoiDungKhongDinhDanh, MGA73, Minorax, Liuxinyu970226, Ericliu1912, Dmehus, Whym, and SHB2000: Major update to this proposal, please review again and give your comments. Stang 14:41, 6 May 2022 (UTC)
Sounds good to me, even with the deleted history and deleted contribs parts. I also support the reconfirmation process, but have no comment on how long should its expiration be. NguoiDungKhongDinhDanh 14:55, 6 May 2022 (UTC)
  • @Stang: Thanks a lot for the ping. I think it is fine to make it temporary. Since it is possible to see a lot of stuff I also think it would be a good idea to limit it to users that have been admin for some time. I would (still) also like it if users could also undelete a file to retransfer with fileimporter. It should be easy for local admins to find out if someone abuse the right to delete files so I do not think it will make it risky. So I still support. --MGA73 (talk) 17:20, 6 May 2022 (UTC)
@Stang: Still looks good. -- Jeff G. ツ (please ping or talk to me) 21:29, 6 May 2022 (UTC)
Still great enough I think. —— Eric LiuTalk 12:28, 9 May 2022 (UTC)
Since WMF has declined similar proposal before, I would like to ask for on hold this GFDR proposal until it is accepted by WMF legal team. Although there was a previous GFDR RFC in 2014, it is about 8 years ago and the international law has been changed significantly (e.g. GDPR). Thank you. cc@AKeton (WMF): SCP-2000 04:43, 16 May 2022 (UTC)
Note: I have sent an email to Legal team already, which request for a legal review for this proposal. SCP-2000 04:18, 1 June 2022 (UTC)
  •   Oppose I don't really see a frequent need for this tool here to warrant a new user-group. In rare cases where this might be needed requesting local admins, or steward/GS seem to be a good idea. Consulting local admins regarding those files seem like a proper way to do things to me. Even though the scope of this group is limited, I don't think creating a global group specifically for this purpose instead of going through local process when/where needed is a good idea.--BRP ever 05:47, 16 May 2022 (UTC)
  •   Oppose per BRP, and because enabling access to Special:DeletedContributions as necessary with the current user rights seems way out of scope to me. ~~~~
    User:1234qwer1234qwer4 (talk)
    23:29, 16 May 2022 (UTC)
  •   Oppose per the questions and answers at the top. Question "Q: Who can request for this group?", which is answered "A: Commons Admins and VRT permission agents, or someone else with a valid reason." This is a highly sensitive right, and needs eligibility defined far better than "someone else with a valid reason". SQLQuery me! 04:52, 22 May 2022 (UTC)
  •   Oppose This request is fundamentally ill-conceived; it is motivated by someone having discovered a proposal to create this group in the past rather than anyone in the 2020s independently wanted. I furthermore oppose, as a general principle, groups with large numbers of auxiliary rights unrelated to their intended purpose, like "deletedhistory" in this case, as too prone to misuse not foreseen by the people who proposed their creation. * Pppery * it has begun 15:10, 22 May 2022 (UTC)
    @Pppery: Do you think logging (of viewing actions, as discussed above) will sufficiently prevent misuse? If so, we might want to push for the implementation of that. whym (talk) 14:09, 23 May 2022 (UTC)
    I didn't get that ping, but no, I would oppose regardless. * Pppery * it has begun 16:34, 23 May 2022 (UTC)
    What would be sufficient? whym (talk) 13:29, 26 May 2022 (UTC)
    A change to the software to make viewdeletedfile (or any other rights granted to this group) only allow viewing deleted files and nothing else. And I'd still oppose anyway due to the first sentence. * Pppery * it has begun 20:30, 30 May 2022 (UTC)
    When you say "only allow viewing deleted files and nothing else", are you concerned about the ability to see the history entries (username, edit summary and date) associated with deleted files? Or the ability to see the history entries associated with deleted non-file pages? I would say the first should be allowed in this context. I can see why someone wants to disallow the second. Sorry if this appears pedantic, but I genuinely want to make it clear.@ whym (talk) 12:07, 31 May 2022 (UTC)
    I mean the second, which I got the impression was being allowed here and should not be. * Pppery * it has begun 14:21, 31 May 2022 (UTC)
  •   Strong oppose Viewing deleted content is generally considered to be quite sensitive. I feel that creating this new global group will shift file deletion decisions to be done in a more centralized fashion, which is against the principle of self-governance of individual Wikimedia projects. It will also make it easy to "override" cases when a local admin intentionally declines to provide a deleted version of a file to the requesting party. Last but not least, I'm afraid scope of the newly-proposed group will conflict with other already existing groups: On large wikis, communities will likely be in favor of opting out (it can be already seen with the currently existing global groups). On the smaller wikis, we have already other groups that have the needed rights (global sysops). --Martin Urbanec (talk) 18:56, 22 May 2022 (UTC)
  •   Oppose per above. Aside from the obvious security risks, I just don't see a good reason why local admins shouldn't be consulted first. Sounds like a solution in search of a problem. -FASTILY 07:19, 2 June 2022 (UTC)