Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2021/08.

COMMONS DISCUSSION PAGES (index)
Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Proposal to create a new user group that can view deleted files[edit]

Page-viewers can view deleted pages and request undeletions, but cannot undelete any files themselves.

I would like to propose the creation of a new user group known as "Page-viewers", these users would be able to view deleted pages and have a button that states "Request undeletion" which will create a request at the undeletion requests in the same manner that all other users can nominate pages for deletion. Now because page-viewers get access to copyrighted content they will have to be elected in the same manner as administrators, but because this user right has a lot less responsibilities it will likely be easier to pass for those who need the right.

  • Pictogram voting comment.svg The need for page-viewers, as more files ascend to the public domain Wikimedia Commons has a larger amount of files that have once been deleted that are now in the public domain. When Wikimedia Commons was created in 2004 a lot of files that were then copyrighted are now in the public domain and not all deleted files are tagged with "Undelete in 20XX". As more files will enter the public domain in the future I believe that while initially only a small number of users will be granted this right (probably only a few dozen in the coming decade), I expect this to be a much more viable right in the long-term future.
Furthermore, I remember several years ago that there was a proposal to let OTRS volunteers have the ability to view deleted files, this proposal failed primarily because of the fact that many users commented that "OTRS members are not trusted users regarding to Commons point of view as they are not appointed by the Commons community." This would fully solve the trust issue with this as OTRS members would have to be vetted by the Wikimedia Commons community to be able to view deleted files and they still won't be able to undelete files directly.
  • Pictogram-voting-question.svg Who should be page-viewers?, By preference, most page-viewers would be license reviewers with years of experience and/or already have a good record of requesting undeletion. As noted above OTRS / VRT volunteers that are trusted by the Wikimedia Commons community should apply as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:23, 12 July 2021 (UTC)

Votes (Page-viewers)[edit]

  • Symbol support vote.svg Support, as proposer. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:51, 12 July 2021 (UTC)
  • Symbol support vote.svg Support in principle. There have been many times that I've been trying to help newbies who had a file deleted and wanted to learn more about why. Often it's straightforward, but other times it's less clear. The nuance of a deletion cannot be understood through the deletion log in many cases, and it would be useful to be able to just take a quick look. There have also been many times where I wanted to learn more about Commons' history with a particular subject (say, freedom of panorama). It would be useful to be able to see where lines have been drawn in the past by seeing what has been deleted. This is, of course, all in addition to Donald's reasoning. One point, though: I don't think this should require an election. Just add it to COM:PERM and set forth some requirements. — Rhododendrites talk |  21:36, 12 July 2021 (UTC)
Symbol support vote.svg Support per nom.   — Jeff G. please ping or talk to me 03:56, 13 July 2021 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose At Commons the most prominent deletion reason is copyright violation, so the content is deleted because it may not be published. It would be against the intention of everything we like to achieve here if we allowed additional users to view such content without having a definite rule set who this right shall be granted and used. The current regulation is that only admins may view deleted content, and we have procedures how to appoint and remove admins. Project goal is not to establish as many new rules as possible, please keep it simple and request regular adminship if you need it. --Krd 04:23, 13 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose There is a reason why files get deleted. Deletion means that nobody should see it, because it violates the law or the rules of commons. And besides that, there is a set of users that already have the right to view deleted files, and they are called admins. All it does is that already deleted files will be discussed a second time... a third time... All the while there are thousands of new files every day that need review and there is a backlog of months on files that are nominated for deletion. If you honestly "need" that kind of user right, there is a way to get it: get elected as admin.--Giftzwerg 88 (talk) 07:06, 13 July 2021 (UTC)
    • How does the backlog on deletions have anything to do with this? And what's wrong with discussing deleted files a second time in some cases? It's no different than having a second DR on the same file, which happens sometimes for good reasons. We should not stop valid undeletions on grounds of backlogs or whatever.--Prosfilaes (talk) 00:15, 2 August 2021 (UTC)
  • Symbol oppose vote.svg Oppose -- (talk) 10:03, 13 July 2021 (UTC)
  • Symbol support vote.svg Support, with standard election procedure, per nom.  Mysterymanblue  16:51, 14 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose as per Krd and Giftzwerg - Most deletions are copyvios and I also agree that admins should be the only ones to see the content and to have it undeleted. Apart from that DR amongst other places are already full to the brim - Do we really need another backlogged venue? Obvious answer is no. I appreciate Rhododendrites' sentiments above but I still believe there's no need for this right. –Davey2010Talk 19:42, 14 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Davey--A1Cafel (talk) 09:18, 21 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose Unless we hear from the WMF Legal team that they would be fine with this. I think that, from a copyright point of view, the legality of an user group (admins) still able to view content that was "deleted" for copyright reasons could already be questioned, but I hope this will continue to be allowed, as only in this way we are able to process undeletion requests and restore files that went into the public domain after deletion or were wrongfully deleted. But for copyright reasons, this user group can not be made too large. It must remain restricted. Maybe a very small "page viewers" group would still be okay, but then, it would seem to add unnecessary complexity - just elect a few administrators more. Gestumblindi (talk) 09:48, 21 July 2021 (UTC)
  • Hell no, this would be a privacy nightmare. pandakekok9 11:45, 23 July 2021 (UTC)

Discussion (Page-viewers)[edit]

  • Pictogram voting comment.svg Notes: Following a village pump discussion I have decided to change the proposal to be among the many "admin lite" / "sysop lite" user groups I wish to propose and I will no longer propose that this user group be divided into "levels" (as I had originally done, where it would be divided into 3 (three) levels where some users can view more sensitive pages and only those are elected) as this user right will be fully electable if accepted, meaning that maximum trust is already required. This solves both any potential legal ⚖ issues raised by the WMF and not "water down" the trust required for those who deal with such sensitive files.
They will have an election process identical to administrators, but I imagine that they will receive less scrutiny as they will not be able to block/ban users, delete pages, undelete pages, give user rights, Etc. So the question is only if we trust them enough to see sensitive content, which is still a huge responsibility and needs to be properly vetted and I expect only those with good reputation to acquire the trust of the Commonswiki community. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:59, 12 July 2021 (UTC)
  • @Rhododendrites:, the election part is very much necessary, as otherwise the WMF will essentially "veto" it, as you can see in the linked archive to the previous proposal from 2017 and the decades such discussions have gone on Wikipedia, it is necessary for this user right to be vetted for it not to become a legal liability for the Wikimedia Foundation (WMF). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:51, 12 July 2021 (UTC)
    • Could you highlight where in the discussion it arises that the WMF would veto community processes other than elections? Allowing people who have already been granted OTRS access the ability to view deleted files would circumvent any vetting for that tool in particular, and many OTRS volunteers aren't active at all on Commons. But here we vet reviewers, GW toolset users, template editors, etc. locally, in addition to admins... just not through elections. — Rhododendrites talk |  21:58, 12 July 2021 (UTC)
      • Specifically at "Symbol oppose vote.svg Oppose mostly because the WMF has repeatedly stated over at enwiki that they will shut down any attempt to grant editors the ability to view deleted files unless it stems from a community process. Even if this got approved, the WMF would just shut it down. ~ Rob13 Talk 02:20, 10 March 2017 (UTC)", also in the Village pump discussion where I received feedback from Alexis Jazz on Wikipedia I noted these concerns. Trust is indeed always involved with user rights, but this is a legal issue and essentially would open the door for more "admin lite" / "sysop lite" user groups through similar processes in the future. Wikimedia Commons has large backlogs and having more users take the workload off of admins should be welcomed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:10, 12 July 2021 (UTC)
        • Right, and as I said, COM:PERM is a community process. I don't see a requirement that it be an RfA-like election -- just a community process. — Rhododendrites talk |  19:15, 13 July 2021 (UTC)
  • @Krd:, replying to "It would be against the intention of everything we like to achieve here if we allowed additional users to view such content without having a definite rule set who this right shall be granted and used." the process would be exactly the same as asking for regular admin rights and many OTRS / VRT members that now frequent UnDR will likely request it, asking for regular admin rights means that we should trust these users with also deleting, undeleting content, blocking/banning users, giving user rights, Etc. which requires a lot more trust, but this user right only requires trust in dealing with deleted files and the users will be vetted in a manner identical to the admin process, it wouldn't introduce any more complicated rules, just apply existing rules to a group of users that want a single admin right, kind of how rollback was exclusive to admins many years ago, but because this content is more sensitive still requires wide community support on a person to person basis. Plus this would also fulfill the ability "for the OTRS agents to finish their work without needing admin assistance in every case" you supported ten years ago at "Commons:Village pump/Proposals/Archive/2011/11#OTRS member permissions" just now they would need community support before viewing such files.
Also, I think that a lot less users would pass RFA if all admins had checkuser and bureaucrat rights because those require more trust than "regular" admins, new user rights are usually created for a reason, because we wouldn't trust a user to do A to must have the ability to do B if they only have experience with A. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 04:45, 13 July 2021 (UTC)
  • None of your arguments is in opposition to mine. I still think that VRT members could have this as a part of their role, not by a separate process, but this is unlikely to happen. As far as an open process is concerned that is available to anybody, I'm opposed. We cannot grant participation in copyvio sharing just honorary. Even the possibilities introduced for VRT members (undel req page on VRT wiki, etc.) are not used at all, so at first a real need shall be shown. Do you have any numbers how many VRT agents are active on commons who are not admins and not likely to pass a RFA? --Krd 05:53, 13 July 2021 (UTC)
    Jeff G. is a VRT volunteer that failed RFA 4 (four) times, but I think that they are very unlikely to not be elected to become a Page-viewer, yet their name often pops up at UnDR and they even his own preload for UDR's. If an entire category gets deleted because the author's / sculptor's death was 65 (sixty-five) years ago and then someone wants to request undeletion five (5) years later then they can already filter out the good uploads from the bad (as in the one with more issues such as other copyrighted features or simply blurry photographs) saving the undeleting administrators time and work. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:45, 14 July 2021 (UTC)

Does "page" actually mean page, or does it mean "media file" in this proposal? Would it not make sense for the proposal to be requesting access to deleted media files rather than a right to undelete pages? -- (talk) 19:24, 14 July 2021 (UTC)

@:, depends on what access is needed, Wikimedia Commons is primarily media orientated but I don't see any benefits in disallowing them to also see other pages. Regarding the final question, that is what the proposal is, these users wouldn't be able to undelete anything only view deleted pages and then they would still have to ask administrators to undelete it for them. As I expect them to be elected from experienced license reviewers I don't expect them to file any bad requests to delete an image of a statue or work of architecture made by a Russian that died 60 (sixty) years ago or something because rookies likely wouldn't get this right. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:45, 14 July 2021 (UTC)
I don't know how that would work. My experience with sysop tools is that with "View and restore deleted pages" you undelete files to look at them, though you can be selective with which revisions are made visible so can restore a file with just a blank text page. I think there's no easy interface to show users deleted files without making them visible on-wiki. Happy to be corrected if there's some special Commons utility. -- (talk) 19:56, 14 July 2021 (UTC)
@: I was under the impression that those are different user rights at the top of "Commons:Village pump/Proposals/Archive/2011/11#OTRS member permissions" viewing and undeleting were listed as separate, a number of users also wanted OTRS members to see files without having the ability to undelete them. I deliberately made this proposal based on the "feedback" from that one as I believe that restoring deleted pages should still remain an exclusive admin right. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:05, 14 July 2021 (UTC)
Could do with some screenshots of a test file to show what we are talking about. I don't think this is in the standard mediawiki software, that is to say, even if the rights exist, the functionality of the software may not do what you expect.
(Supplemental) At the back of my mind there's a discussion of this from several years ago. A benefit of forcing users to undelete on-wiki during, say, an UNDEL challenge, is that single user only previews of deleted files would be unlikely to leave any logs. Just as Checkusers have special requirements due to the potential for abusive use, there are abuse scenarios when there are no public logs that this raises, including files thought unlawful, abusive or damaging if harvested and published elsewhere. As a proposal, this needs to be underpinned by the detail of the workflow to ensure people understand the extra risks to this project and our contributors that this might introduce. -- (talk) 20:34, 14 July 2021 (UTC)
@:, according to Ruthven admins can see how a deleted image looks like. So images don't need to be undeleted to be viewed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:05, 22 July 2021 (UTC)
Okay. I have no idea how this works as it cannot be via the View and restore deleted pages interface. The only options are undelete, undelete specific revisions, or suppress deletion visibility i.e. some deleted file versions can be less public. If a sysop can do this, I would like to see the specific guidelines that sysops are supposed to follow for when to use it and how. -- (talk) 15:25, 22 July 2021 (UTC)
Example for "Page history" and "File history"
@: For admins, it's actually possible to view "deleted" images via the View and restore deleted pages interface without having to restore them. I have included an example screenshot to show how this works: You will notice that there is a "Page history", and below this, a "File history". If I click on the date in the "File history", I can access the deleted file. It's displayed immediately, no need to perform a restore action first (but stays "deleted"). I guess it would be impossible to handle undeletion requests and similar cases properly if this weren't the case. Gestumblindi (talk) 18:11, 22 July 2021 (UTC)
Thanks, I now see it in practice. The target link includes a "&token=172d043ef..." style token link. I would guess there's a log of these deleted file accesses somewhere, the point of the autogenerated tokens, so they can be audited if there was a security issue. It would be interesting to know how the logs can be checked and whether they are public, even if the deleted files are not.
It seems obvious to me that sysops should not be surfing through deleted files out of curiosity, especially if the deletions might be down to privacy-related requests or hounding. -- (talk) 11:40, 23 July 2021 (UTC)
  • @Davey2010:, this is to reduce backlogs and not create them. These users can help admins at UnDR's by viewing copyright violations and voting them down, perhaps these users might even be able to close denied undeletion requests reducing the administrative backlog. Further "Most deletions are copyvios", well, copyright doesn't last forever and it eventually expires and not all files uploaded that could be undeleted in 2025 are tagged as such and it would be unreasonable to expect the few hundred administrators to also patrol already deleted files to see if they should be undeleted. Many files that are deleted are files from the 1950's and 1940's with improper sources, a Page-viewer can research a file based on what they can see, you can't file an undeletion request for a file you barely know anything about. Also note that things like authorship and sources are also in file descriptions (because not all new users know that they shouldn't add "Own work" if it comes from their own collection). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:52, 14 July 2021 (UTC)
  • The proposal states "have a button that states "Request undeletion" which will create a request at UDR so therefore UDR would get backlogged wouldn't?, UDR needs a massive overhaul (ie it needs to get rid of the !voting side) but that's another discussion for another day.
Fair point but I would simply hope the editor reuploads historic content in the appropriate year - not have someone go through all old files and !vote undelete as to be blunt that's just wasting your life away ...., I'm just not seeing a need for this right to be honest, –Davey2010Talk 20:12, 14 July 2021 (UTC)
One can always hope, but many people are active only a few years and won't come back when it is time for restoring the file, and only some will keep the file and keep track of when it should be reuploaded. If it is a photo of one's own it may be buried among thousands of other files before the Commons copy is DRed, and the user may not know when the underlying copyright expires – the closing admin is much more likely to know, and those details are often not told in the DR. These are some of the reasons for us to have to-be-undeleted categories in the first place. Ideally those would always be used by the closing admins. –LPfi (talk) 18:27, 22 July 2021 (UTC)
  • Even if a community voting procedure is added to the proposal, I'm still opposed to it. If you're trusted to view deleted files, then you must be an admin. Period. Unbundling of sysop shouldn't be taken lightly. pandakekok9 11:49, 23 July 2021 (UTC)
  • If the concern is that there are many deleted files that may require review in the future, could an alternate proposal be to ask DR closers to indicate when the work is expected to enter the public domain in their closing summary? For example, we could perhaps have a template called "undeletion review", where {{undeletion review|date=2030}} will add the text "This DR is up for undeletion review in 2030" and add Category:Deletion requests up for undeletion review in 2030.  Mysterymanblue  17:28, 24 July 2021 (UTC)
    There are already such categories, such as Category:Undelete in 2030. pandakekok9 01:54, 25 July 2021 (UTC)
Ah, thank you.  Mysterymanblue  03:39, 25 July 2021 (UTC)

@Pandakekok9:, just curious but how would this be "a privacy nightmare" if we already have an elected group of users with exactly these rights? What's the difference? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:56, 8 August 2021 (UTC)

The proposal seem to implies that the vetting procedure for these "page viewers" would be similar to license reviewers, which obviously is less strict in its vetting process than RfA. Hence the "privacy nightmare". The privilege to view deleted files is not something that should just be given so easily. As some opposer pointed out, a lot of our deletions are due to legal issues.

But what if we make the vetting process as strict as RfA? Well then your proposal is moot then. If you're trusted to view deleted files, you must be trusted to have the full set of admin tools then. pandakekok9 13:29, 8 August 2021 (UTC)

It is not the same, trusting a user the ability to permanently kick out other users requires a lot more trust than viewing pages others can't. Bureaucrats and Checkusers essentially go through the same process, should we give all admins Bureaucrat and Checkuser rights because they are trusted anyhow? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:14, 4 September 2021 (UTC)

Policy of a default of standard blocks to reduce reliance on checkuser blocks[edit]

This proposal is to qualify the Wikimedia Commons blocking policy on checkuser blocks(1) with the additional sentence:

  • When no data critical to a block decision needs to be kept confidential, or when relevant data that justifies a sufficient block action is already public, such as the identification of related sock accounts, a standard block managed by administrators will be the default in preference to a checkuser block.

The key benefits of this technical procedural amendment are that fewer blocks will require ongoing management by the small Commons checkuser team, the block appeal process will be simpler to understand and discuss in the wider community, and there will be improved transparency and accountability for the blocking process in these cases where specific records of checkuser evidence is not fully critical to block or unblock decisions. This may also encourage administrators with checkuser access to limit their use of their trusted role as checkusers by handing off block or unblock decisions to the Commons admin team, or simply making a recommendation where the checkuser evidence is controversial or not 100% conclusive on its own; for example when logs of comments in browser header data may be perceived by some to be "rude" but only supplements critical patterns of bad faith public comments by an account that can be handled by a conventional block.

References:

  1. Commons:Blocking policy#Checkuser blocks
  2. Commons:Checkusers
  3. m:CheckUser policy
  4. {{Checkuserblock}}

Note that an unblock appeal for a Checkuserblock "must only be reviewed by a checkuser".

-- (talk) 10:49, 30 July 2021 (UTC)

Votes (reduce checkuser blocks)[edit]

  • Symbol support vote.svg Support as proposer. -- (talk) 10:49, 30 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose as a solution is looking for the problem. --Mirer (talk) 13:27, 30 July 2021 (UTC)
    No, it very much is a current problem. This was the recent practical issue with this case. There was no especially good reason for a controversial block like this, where all the information about it was public, to be only discussed in secret with checkusers. Where policies embed unnecessary secrecy, they should be improved to ensure all reasonable transparency. -- (talk) 13:31, 30 July 2021 (UTC)
  • Symbol support vote.svg Support Increases transparency and simplifies the process.  Mysterymanblue  14:08, 30 July 2021 (UTC)
  • Symbol support vote.svg Support per all above - CU blocks are useful when for certain reasons data has to be kept secret but they're not useful when in the case of Alexis there was nothing that had to be kept secret, CU blocks can simply be done as an authoritarian thing like it was done with someone above. –Davey2010Talk 14:41, 30 July 2021 (UTC)
  • Symbol support vote.svg Support as a principle, but I hope not with the intent of ever taking disciplinary action against someone with checkuser privileges who might get this wrong. - Jmabel ! talk 14:56, 30 July 2021 (UTC)
Agree, I was more imagining this amendment mostly making checkusers consider this a more normal option, and making a polite discussion more reasonable to have, rather than a debate or litigating the evidence; like "Could this be made a non-CU block as there's lots of public evidence in this case, please and thank you? Er, okay, done. Thanks!" -- (talk) 15:07, 30 July 2021 (UTC)
  • Symbol support vote.svg Support in principle but with details on what this actually means in practice to be worked out below. -- King of ♥ 16:37, 30 July 2021 (UTC)
  • Symbol support vote.svg Support 1989 (talk) 17:41, 30 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose When there is confidential information that warrants a CU block, there is no chance to make it public, so by nature it is impossible to publicly support a CU block. IMO this is a complete nonsense proposal. --Krd 18:26, 30 July 2021 (UTC)
    The point is that in the Alexis Jazz case, the CUs found a sock and disclosed that publicly, and blocked him for it. It appears that there is no private evidence in support of that block other than that which is necessary to prove that Alexis Jazz = Grilling the Sheriff. In such a case, CUs do not actually have any more information than the community as a whole, and so should not be afforded a privileged position in the review of these kinds of blocks. -- King of ♥ 18:41, 30 July 2021 (UTC)
    Without me saying if there was or was not any additional information, from what do you conclude that there wasn't additional information? From that the CU team didn't document anything, especially no confidential information they are not allowed to disclose? --Krd 18:55, 30 July 2021 (UTC)
    I consider it basic accountability for the CU team to disclose publicly whether there was material private evidence that went into the block which has not been revealed publicly, and the rough nature of such evidence. Without this documentation, CU blocks should not be used. The "everything is classified" mentality has worked terribly in the real world, and I don't want it to pollute our wiki. -- King of ♥ 19:15, 30 July 2021 (UTC)
    Fair opinion, but please allow me to disagree. I'm a bit proud that in such an open environment like our's, we are still able to keep confidential information undisclosed to protect the privacy even of abusers. --Krd 19:53, 30 July 2021 (UTC)
    King, I wonder if you could give an example of the evidence that you would like to see disclosed, that meets all of the following criteria:
    1. the CUs are allowed to disclose that evidence (per policy),
    2. it is actually useful to the community (e.g., to future admins or uninvolved editors; by this, I mean to say that it's not basic/background information about what CUs do), and
    3. it would not be helpful to blocked/banned people who are trying to evade detection (e.g., does not say "matching IP address", because then the sockmaster knows to seek a different IP address).
    I'm trying to understand what "the rough nature of such evidence" would look like in practice. WhatamIdoing (talk) 20:15, 30 July 2021 (UTC)
    I suspect in a vast majority of CU cases, the answer will just be "no material undisclosed evidence". This means that the accounts are publicly linked, and there's nothing complicated going on like suspected sleepers, proxy-hopping, etc.
    Anyways, I think what I'm really going for is this: In obvious cases where they feel they have no more useful private info to make use of, CUs should consider making a normal block. In more complex cases, CUs can continue to require unblock reviewers to check with the CU team before unblocking. But if the community reaches a consensus to unblock, CUs should not have veto power over the community. In that case, if the CU team believes that the user should remain blocked, they can make a case to the community, disclosing however much information they wish, to influence the consensus. But ultimately the community reigns supreme. The CUs can choose to disclose nothing at all, and then it is up to the community to take them at their word or reject it absent further evidence. -- King of ♥ 20:33, 30 July 2021 (UTC)
    Nothing in this proposal suggests that anyone has to "publicly support a CU block". This oppose seems unrelated to the actual sentence being proposed to clarify BP. It would be great if folks could take a moment to understand what the proposal is, before voting on it. -- (talk) 10:27, 31 July 2021 (UTC)
  • Symbol oppose vote.svg Oppose Commons:Blocking policy#Checkuser blocks: Our policy is sufficiant, a checkuser block is supposed to be made "on the basis of technical checkuser evidence". By definition those evidences are private informations, so as it was well said by Krd there is nothing to discuss. Furthermore such policy will give the chance to anyone about to be blocked for abusing multiple accounts to escpade a checkuser block by making public some infos before to be blocked. It's not for nothing that currently the potential unblockages after CU blocks have to be reviewed by a CU.... they have to check... hence their name "checkuser". Furthermore I'm clearly not enthousiast to change a policy just for one case, because it is clear that the block of Alexis Jazz‎ is the departure of that. Christian Ferrer (talk) 21:04, 30 July 2021 (UTC)
  • Also note that only case, Alexis Jazz, have been unblocked quicky after their first unblock request, so I wonder why this proposal would have changed something, i.e.: a user has disruptive behavior → the user gets blocked → private infos are being kept privates by CUs, as it should be → the user aknowledged his behavior and made an unblock request → the user gets quickly unblocked. It will be hard to make me understand how the process have failed here. And I wonder if it possible to have a list of different examples where this proposal would make a usefull difference, explaining why and how. Christian Ferrer (talk) 05:17, 31 July 2021 (UTC)
  • Symbol support vote.svg Support The limitation on reversing checkuser blocks is due to the private nature of checkuser evidence; if the evidence isn't private then there's no need for a limitation on unblocks. IMO this is already covered by Commons:Blocking policy#Checkuser blocks, but evidently that isn't crystal clear, so the additional clarification of this proposal is helpful. -M.nelson (talk) 23:35, 30 July 2021 (UTC)
Symbol oppose vote.svg Oppose per Mirer, Krd, and Christian Ferrer.   — Jeff G. please ping or talk to me 04:57, 31 July 2021 (UTC)
  • Symbol support vote.svg Support, on Wikimedia websites we have a culture that can best be described as "Blocks are easy and unblocks are hard nearly impossible", very few indefinitely blocked/banned users ever get unblocked/unbanned and a common thing users do is sock to evade the block, if they get caught this then becomes a Checkuserblock and that makes an already difficult unblock process even more difficult. Officially blocks and sanctions only exist to prevent disruption, but if a user was blocked 10 (ten) years ago for uploading copyright violations, sock to continue and then get Checkuser blocked, and then returns after a decade to upload good images and return with absolutely none of the same issues they had prior we shouldn't be punishing them for believing in the educational spirit of Wikimedia Commons by letting them appeal through a very difficult process. While this won't make all unblocks easier this will make some unblocks easier and something tells me that the best way to stop a Sockmaster is by letting them return legitimately, this saves everyone work. Letting an unblock be dependent on half a dozen users rather than a few hundred isn't beneficial for everyone and if all the information of the CheckUser case is already publicly available then CheckUser input doesn't really add anything. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:16, 4 August 2021 (UTC)
    @Donald Trung: "all the information of the CheckUser case" has never been "publicly available" for reasons of privacy. The functionaries sign legal agreements to that effect and police themselves as a team, as we elected them to do. If we need more of them, we can elect more. If they misbehave, we can vote them out.   — Jeff G. please ping or talk to me 11:37, 4 August 2021 (UTC)
    Just to avoid any misunderstanding, this proposal makes zero changes to how confidential checkuser information is kept confidential. -- (talk) 08:42, 6 August 2021 (UTC)
Symbol oppose vote.svg Oppose per Krd and Christian Ferrer – and my comments below. --AFBorchert (talk) 17:22, 7 August 2021 (UTC)
  • Symbol support vote.svg Support--A1Cafel (talk) 15:59, 14 August 2021 (UTC)
  • Symbol neutral vote.svg Neutral I think this is actually covered by existing policy -- as noted by Christian above, a CU block is not to be used unless there is non-public supporting evidence -- "on the basis of technical checkuser evidence". Therefore I see no reason for it, but equally, no harm in it. In a way, it's a little strange that it presumes that there is a need for this additional rule because CUs do not always obey the existing policy, but trusts the CUs to obey the new rule. .     Jim . . . (Jameslwoodward) (talk to me) 13:15, 26 August 2021 (UTC)
    It's not an additional rule, the proposal uses "qualify", i.e. "extra detail or explanation". It seems remarkable how folx, including checkusers, have read presumptions in the proposal that, as the proposer, I know are not there. -- (talk) 17:52, 26 August 2021 (UTC)

Discussions[edit]

i think the checkusers should specify the sock master either in the block log or on the user talk page. sometimes it's quite hard to find out who exactly operated the sock.--RZuo (talk) 13:21, 30 July 2021 (UTC)

  • Pictogram voting comment.svg Comment I think on Commons, checkuser blocks can always de facto be overturned by community consensus. This is not true on English Wikipedia, where any admin who tries to implement such a community consensus might find themselves desysopped by ArbCom. Our desysopping process belongs to the community alone, so we obviously would not desysop an admin over an action that was taken with the support of a majority of the community. -- King of ♥ 14:29, 30 July 2021 (UTC)
No, the Wikimedia Commons checkuser team believes they have the authority to desysop any administrator that removes a checkuser block without their permission. COM:BP does not state this, but it does say that only checkusers can remove a checkuser block. This amendment better defines the scope of that authority.
The current interpretation of policy is that checkusers can ignore any community consensus about their actions, though the community could ultimately remove Commons checkusers by running desysop votes, which they could not ignore or override. However, no Wikimedia Commons vote or community consensus could do anything about global stewards or WMF staff who choose to give themselves checkuser access or take other actions. -- (talk) 14:33, 30 July 2021 (UTC)
The key difference is that English Wikipedia has ArbCom, and Commons doesn't. On Commons the only desysopping mechanism is via a Request for de-adminship. Checkusers do not have the technical ability to desysop users, and there is no policy that would allow a crat or steward to desysop an admin upon request by a checkuser. -- King of ♥ 14:42, 30 July 2021 (UTC)
In any case, this proposal appears to be an attempt to regulate CU behavior, but it is unclear what the enforcement mechanism is. Is it a strictly a behavioral issue, i.e. checkusers who repeatedly violate the provision and improperly label a block as a checkuser block will be subject to community de-CU? Or is the community allowed to challenge the status of an existing block as a checkuser block, and have it declared a normal block regardless of what the checkuser originally said? -- King of ♥ 14:48, 30 July 2021 (UTC)
Well, theoretically perhaps. But consider that one of the 'crats is in the Commons checkuser team, hence in their private email list. Further, the checkuser team could defend their authority by placing a checkuser block on any sysop who reverses their decision, then threaten to place checkuser blocks on any sysop that tries to reverse that. No doubt the 'crats would pretty much have to support checkuser decisions made in private anyway. I seriously doubt any of this would ever happen, as I presume that the vast majority of sysops, as well as checkusers, would understand it as a symptom of a serious breakdown in trust.
With respect to your last point, the community does not formally have any power to challenge a checkuser block, but as in the recent case, ignoring serious community discussion about a possibly unfair block, or claiming a community consensus has no "technical" authority, is a very bad place for checkusers to choose to remain standing as ultimately, they can all be desysoped and we (the wider community on Commons) can vote in a new set. -- (talk) 14:55, 30 July 2021 (UTC)
I don't think "removal of all CUs when they defy the community" is a good final enforcement mechanism (as I think you are implying; it seems you are just suggesting an exhortation for CUs to "play nice" before it gets to that stage). Instead, we should just amend the policy to make it clear that the community always has the authority to overturn checkuser blocks via consensus. -- King of ♥ 15:05, 30 July 2021 (UTC)
That's a separate discussion, but could be a separate proposal. However, I doubt it would pass as there are always cases where CU evidence really should stay confidential, such as when there are legal issues or serious personal harassment that is inappropriate to discuss in public. CUs should be fully trustworthy to make those judgement calls, if not, then there's a problem with the nomination and election process. -- (talk) 15:10, 30 July 2021 (UTC)
And the community would respect the CU's judgment in such cases as long as a reasonable explanation is given why the info needs to be kept private. We can view your proposed wording as a guideline not only for checkusers, but for the community. That is, we trust checkusers to label their blocks correctly in line with the policy in a vast majority of cases, but the community has the final say on whether something is a checkuser block. -- King of ♥ 16:36, 30 July 2021 (UTC)
Yes, rereading your words here, ultimately accountability is to the wider community and a necessary responsibility of the wider community. The fact is that checkuser rights have been abused in the past (I'm thinking of cases on other projects) and if either the checkuser policies or their implementation leads to unfair treatment of users, then the wider community needs to be able to know those failures have happened and needs to be assured that corrective and preventative action has and will be taken. Too often the failures are classified as "confidential" or have "private" implications when an open examination of the facts would be far more beneficial long term and reporting the facts would involve no exposure of private data.
After over 15 years contributing to these projects, I fully understand that failures happen and systemic bias is impossible to eliminate; that doesn't mean we should not seek to improve. -- (talk) 09:58, 4 August 2021 (UTC)
  • Pictogram voting comment.svg Comment I do not think that the case of Alexis Jazz is the proper example for such a proposal as Jameslwoodward explicitly stated that confidential information was a factor in that case. --AFBorchert (talk) 07:47, 6 August 2021 (UTC)
    Thanks for chipping in AFB. This proposal does not hinge on that case. However that block was controversial at the time it was placed, and it gave the appearance of being heavy-handed as the evidence of socking was uncontested and a matter of public record. As such there remains no obvious justification for insisting that a checkuser block was necessary or that a non-checkuser block would not have been sufficient. There should be a lesson to be learned from that case, it's surprising to see the level of defensiveness by the checkuser team against this incredibly minor proposal, that only clarifies current best practices and makes absolutely zero difference to how the community trusts checkuser judgment over what is or is not necessarily confidential information or when a checkuser block is justified and necessary.
    By the way, with re-reading the statement by James you kindly referenced, I read "permanent block" as a block, if it was supposed to be a ban or something else, this should have been explained. It remains unexplained as to why a "permanent block" could not have been managed as an ordinary block, perhaps with a recommendation from the CU team as to minimum duration. In reality it looks like a 6 month or 12 month block minimum might have been the recommendation at the time, had the CU team chosen to let that be managed by the sysop team. There is an obvious parallel here with how Arbcom does not directly block users, but makes a recommendation based on evidence and that some of that evidence may remain confidential. There's nothing wrong with handling things in that more transparent way, in fact, there are obvious benefits of demonstrating trust in the wider sysop team and a certain suitable humility in the way that trusted roles like checkuser keep their exercise of special authority or powers to a minimum and only when completely necessary. -- (talk) 08:40, 6 August 2021 (UTC)
    Well, even you state that this “proposal does not hinge on that case” it appears to be something like a lex Alexis Jazz and cases like this are pretty rare at Commons. I want to remember that this case was serious and it took (at least for me) some time to see the cross-wiki extent of that case. A “permanent block” is still the maximum here at Commons as we have no Wikipedia:Banning policy (Q6140266) as en:wp. But I still think that Alexis Jazz can be grateful that he wasn't globally banned. In summary, I do not think that we need a policy extension as proposed. I wish, however, we would have it the other way, i.e. if there are no objections by the CU team, we should have an open discussion like we did before where I proposed some preconditions for an unblock.--AFBorchert (talk) 09:55, 6 August 2021 (UTC)
However, it should be noted that you are linking to public statements, therefore the information is public and not in a practical sense reliant on any confidential information. (I'm going to avoid re-litigating any case here, so let's be generic) If someone's behaviour crosses the line into harassment, unlawful material, legal threats or cross-wiki disruption, these are firmly and clearly addressed using existing policies on blocks, global bans or WMF office locks. The decision on whether a case needs a checkuser block, is not down to how "serious" the behaviour is but on whether a block action is reliant on confidential checkuser information.
We know of many cases where contributors, even past administrators, have been "tired and emotional" for whatever reason, and make stupid but hurtful threats of harm to others or themselves. Everyone would agree that obvious cases of long term abusers should result in global bans or locks and associated sock accounts that continue that abuse for very good reasons get quietly locked without public discussion. As a founder of WMLGBT+ I am aware of plenty of cases where people are targets of long-term abuse, including the threatening use of real-life information, over many years, and it is a necessary part of our policies to ensure that people who are targeted with abuse or persistently unfairly treated have support and protection to contribute in a non-hostile environment. Thumbs up to all that.
However just as WMF T&S are re-examining the conditions where they can better provide for natural justice (i.e. a right to a fair hearing, protection against bias and provision for reasonable individual reform) the avoidable use of checkuser blocks should be a matter of community examination and improvement. The forthcoming implementation of the UCoC may be an opportunity for this to happen across projects.
In all cases we should follow an approach of necessary and sufficient enforcement and especially when cases may be an aberration which for all we know may be due to transient mental health issues, obsessive behaviours which may improve over time, or where the process of a proper appeal may reach a joint understanding of how a person can contribute without creating a hostile environment for others.
This reads as a bit of a tangent to this one line proposal, but the point of this proposal is a slight nudge in this direction of fairness and better transparency. I expect you have an interest in seeing these types of improvement, I hope that the majority of the checkuser team do, however for many reasons Commons policies in this area appear entrenched and hard for volunteers to revise or even discuss without so much work it's no longer really a job for an unpaid volunteer. -- (talk) 10:27, 6 August 2021 (UTC)
Again, {{Checkuserblock}} has been used 121 times in total including a good deal of IP addresses and non-user pages. In the blocking logs we will find significantly more cases without an associated notice on the talk page but this is mostly reserved for socks with little activity. The non-trivial cases are rare and a checkuserblock, as I understand it, is per definition based on non-disclosed information. This has naturally to be reviewed by the checkusers who have access to the full non-public information. Hence, I still do not see why we need to revise policy here. And you surely do not want to discuss “transient mental health issues” in public, or do you? --AFBorchert (talk) 13:36, 6 August 2021 (UTC)
This proposal is a minor clarification of policy. How many accounts it affects is not that germane.
If there is something you wish to raise in a different thread, I'm happy to be part of a public discussion about ensuring our project's policies do not have an implicit bias against volunteers with mental health issues or who are not neurotypical. I'm no expert, though I have friends and family members that make these judgments and assess claims based on mental health every day. There are folx on our WMLGBT+ network that have experienced bias against them because of perceived mental health status and on some of our projects simply identifying as LGBT+ can make you a target of allegations of having a mental disorder. As for me, I think I've only had death threats and allegations that I'm sick, that seems to be the normal hostile environment we are supposed to put up with if you hang around long enough. -- (talk) 15:50, 6 August 2021 (UTC)

Remove "In case this is not legally possible..." from {{PD-because}}[edit]

Proposal (PD-because rewording)[edit]

{{PD-because}} is a catchall template that is used for situations where another public domain tag cannot be found. Currently, the text of this template reads as follows:

"This file is in the public domain, because <reason>

In case this is not legally possible:

The right to use this work is granted to anyone for any purpose, without any conditions, unless such conditions are required by law.

Please verify that the reason given above complies with Commons' licensing policy."

The proposal is to strike the words "In case this is not legally possible: The right to use this work is granted to anyone for any purpose, without any conditions, unless such conditions are required by law." from the template.

Reasoning (PD-because rewording)[edit]

The struck words only apply to cases where a work has entered the public domain due to a grant by the copyright holder and where that copyright holder has also granted "the right to use this work... for any purpose, without any conditions, unless such conditions are required by law." This is a very small subset of public domain works, most of which are in the public domain for other reasons (expiration, threshold of originality, other form of copyright abandonment, lack of fixation, out of subject matter, etc.). Removing the language will allow {{PD-because}} to be correct for all public domain works, even those which have entered the public domain for these other reasons. If people need to add the "In case this is not legally possible..." language to the tag, they may easily do so by appending that text to the end of their reasoning.

There may be concern about removing this text from file information pages where it was rightfully included. I respond to these concerns by pointing out that 1) this text has almost certainly been incorrectly included on more pages than it has been correctly included on, and 2) this text is not an integral part of the copyright status of a file, and I cannot image a situation where we would delete a public domain file because the copyright holder had not also provided a licensed fallback.

I am proposing this change here because 1989 declined my edit request on the template's talk page because there was no consensus for the change, presumably due to lack of discussion.  Mysterymanblue  23:30, 1 August 2021 (UTC)

Discussion (PD-because rewording)[edit]

  • Symbol support vote.svg Support as nominator.  Mysterymanblue  23:30, 1 August 2021 (UTC)
  • The reason we have such a text is because in some countries it is not legally possible to declare files as PD. See text on {{PD-self}} as an example. We can perhaps find better wording but I think we need some text. But we should not use the license for new files? So perhaps we can depreciate it? --MGA73 (talk) 17:41, 2 August 2021 (UTC)
    • @MGA73: [Long digression] Actually, there is no country where it is legally meaningful to simply declare a work as public domain (or "release a work into the public domain" as many of our "PD-" templates state. The "public domain" is not a legal entity and is not defined in the copyright laws of any country (including the United States). Legal scholars, the Open Source Initiative, and the U.S. Copyright Office all agree on this. As of 1978, the only way to make a work freely reusable is for the copyright owner to license or waive their copyrights (and those of their heirs). This is why Creative Commons developed the CC-Zero license. The origin of the myth that you can simply declare a file as PD in the US, but not in Europe is that in Europe you cannot license or waive all of your rights in a work (specifically the moral rights). But there is no magical public domain declaration in the US or anywhere else. You still have to specifically license or waive your rights, regardless of the country. And even in the US, you can't effectively abdicate your copyright ownership; you can only transfer it to someone else until it expires. {{PD-self}} is about as legally useful as toilet paper. It is, however, practically useful as a notice that the copyright owner is unlikely to try to enforce their copyrights (although it gives no such assurances about their heirs). Personally, I think {{PD-self}} should be deprecated in favor of {{Cc-zero}}. Nosferattus (talk) 21:36, 2 August 2021 (UTC)
    • @MGA73: That's fine and all, but this is {{PD-because}}, not {{PD-self}}. The proposal only affects files that use {{PD-because}}, most of which are not self-published by the uploader, so the text is unhelpful in most cases.  Mysterymanblue  23:26, 2 August 2021 (UTC)
  • Support if we also explicitly deprecate the use of {{Pd-because}} for own works. Nosferattus (talk) 21:38, 2 August 2021 (UTC)
    • I agree that this should be deprecated for self-published works.  Mysterymanblue  23:26, 2 August 2021 (UTC)
  • Probably, except for cases where the template has been added by the uploader, as own work; in that case the extra wording shouldn't be removed. I think it's generally used for files found on other sites, but it's probably also misused. On File:Oystercatcher pecking the water.jpg, for example, a site apparently made a file available for "for unlimited free use". I don't think that's a public domain dedication, and there's no indication that they agreed to the wording on the template. --ghouston (talk) 00:57, 3 August 2021 (UTC)
    • @Ghouston: if someone add it to own work then we could ask them to choose PD-self or Cc-zero? And if found on some website then we could use PD-author? --MGA73 (talk) 07:13, 3 August 2021 (UTC)
      • We could ask, but there's no guarantee they'll respond. PD-author has exactly the same problem, a fallback license that they didn't agree to. Also PD-because, although it's not one of the more commonly used templates, still has 14527 transclusions, so it's probably impractical to evaluate them all. --ghouston (talk) 12:20, 3 August 2021 (UTC)
    • @Ghouston: I think the fitting template for (copyrighted) files available "for unlimited free use" is {{Copyrighted free use}} and it should just be changed to that one in this case? Gestumblindi (talk) 14:08, 5 August 2021 (UTC)
  • Isn't it extremely difficult in almost all countries to dedicate a work into the public domain? The public domain is a lot like darkness, we don't define "Darkness" as something that is, rather we view it as "an absence of light", likewise the public domain isn't something onto itself it is "an absence of copyright ©" and because of this most intellectual property laws only concern themselves with what is (copyrighted) than what isn't (copyrighted). I can kind of support this proposal with the interpretation that "the public domain" is waving all rights (which it is), but many jurisdictions make this extremely difficult which is why CC-0 was invented, because "© No rights reserved" often isn't recognised by many governments because at all times copyrights are assumed. The global copyright © system is broken and the template tries to accommodate that fact, hence the current wording. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:24, 4 August 2021 (UTC)
  • Symbol support vote.svg Support This template isn't really meant for self-published works and in most cases for which it's used, the "In case this is not legally possible ..." wording is not fitting and confusing, as there isn't any granting of rights involved. I, therefore, also agree with explicitly deprecating it for self-published works, as we have {{PD-self}} for that where the provision is fitting. {{PD-because}} is probably needed so we don't have to create templates for every special case; there are reasons for works being in the public domain that can't be expressed with one of the standard templates, but this is not for releasing copyrighted material into the public domain. Gestumblindi (talk) 14:03, 5 August 2021 (UTC)
  • Symbol support vote.svg Support. Gestumblindi's comment, immediately above ("...in most cases for which it's used, the 'In case this is not legally possible ...' wording is not fitting and is confusing, as there isn't any granting of rights involved") summarises the essential problem. One important use for this template is to declare that in a particular jurisdiction, copyright protection has expired. I use it frequently to specify the authority under Australian copyright law for expiry of copyright, such as here. For that purpose, in the absence of a specific template, it's perfect. The words are not only an irrelevant distraction; they also implicitly encourage misuse of the template (as discussed further above) by uploaders using it instead of an appropriate template. I therefore also support Nosferattus's suggestion that we should "explicitly deprecate the use of {{Pd-because}} for own works." How about: This template must not be used to authorise an uploader's own work. Cheers, Simon – SCHolar44 (talk) 01:58, 7 August 2021 (UTC)
Thank you for the suggestion, Ghouston. I will eventually use {{PD-Australia}}, but right now the template is very much out of date because Australian copyright law has changed since it was written; it's unnecessarily complex; and the source quoted was not issued by the Australian Government. Currently I have opened a discussion on {{PD-AustraliaGov}}, which has similar but fewer shortcomings. After that (and following any improvements that others may propose), I'll be starting a discussion on {{PD-Australia}}. SCHolar44 (talk) 11:14, 7 August 2021 (UTC)
I'd like to add a small PS: When the template is amended, the comma should be removed after "public domain" and the words that follow "because" should be disemboldened. -- SCHolar44 (talk) 11:14, 7 August 2021 (UTC)
And a further PS: I'm a visual person, so I made up a mock-up of what I thought the template might look like, especially after removing the comma after "because", and the emboldening. I also modified my tentative wording for implementing Nosferattus's suggestion and added it below the line:
PD-icon.svg
This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Dialog-warning.svg This template must not be used in connection with an uploader's own work. Instead, the {{PD-self}} template, or another, should be used.

I'd like to suggest another "below the line" sentence. Since the template must not appear on its own unless the image originated in the U.S., I've drafted for everyone's consideration a further suggestion covering PD in the U.S., why it's important, and potential restriction in other jurisdictions:

Unless the jurisdiction in which this file enters the public domain is the United States of America, a statement must follow demonstrating why the file has entered the public domain in that country. This is a precondition for publication in Wikimedia Commons because Wikimedia's servers are located there. In other jurisdictions, re-use of this content may be restricted.

What do people think? -- SCHolar44 (talk) 09:40, 9 August 2021 (UTC)

The layout looks good; just I few things I think would improve this:
  • {{self|CC0}} should be used instead of {{PD-self}} so that people are encouraged to use the better public domain dedication.
  • Not sure why the phrasing "used in connection with" is used. Surely the word "for" is just as good and more concise, as in "This template must not be used for an uploader's own work."
  • A below the line statement about having a U.S. copyright tag is not necessary because the template is not specific to the U.S. For example, someone could write the following in for the reasoning: "70 years have elapsed since the author's death and the work is under the threshold of originality in the United States." That reasoning applies to both the country of origin and the United States. You can also have a situation where someone just explains why the work is out of copyright in the source country but not in the U.S.
  • That being said, we could still have a warning about including both reasonings in general. I would recommend wording more like "This file's page must explain why the work is in the public domain in the United States and the country of origin of the work if the work does not originate from the United States." I am neutral on the inclusion of such a warning.
 Mysterymanblue  17:20, 9 August 2021 (UTC)
@SCHolar44: Nice work, although I agree with Mysterymanblue that we should encourage use of {{self|CC0}} instead of, or in addition to, {{PD-self}}, since CC0 actually has some legal validity to it. Nosferattus (talk) 18:22, 9 August 2021 (UTC)
Great points, Mysterymanblue and Nosferattus -- thank you for advancing things further (and curbing my circumlocution, Mysterymanblue!). Here for consideration is a potential implementation:

This template must not be used for an uploader's own work. Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}} for a public domain dedication.
Amended, shorter wording of 2nd paragraph
If this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain there. In other jurisdictions, copyright law may restrict re-use of this content.
Changes, including added link
If this work did not originate in the United States, there must be an explanation of why the work is in the public domain both in the United States (because Wikimedia's servers are located there) and in the work's country of origin.this statement [[Commons:Licensing#Interaction of US and non-US copyright law|must be]] accompanied by an explanation of why the work is in the public domain in the United States there.

My thinking:
  • I'm keen to give as much guidance as practicable to newcomers, hence the "such as" hint towards {{self|CC0}}.
  • Similarly for linking to the Commons page that explains including the reason why US copyright is so important: in classes that I run in Australia, this requirement frequently produces grumbles about "US control of intellectual property". Then when I mention the servers, there's widespread slapping of foreheads with palms of hands. I bet these people aren't unique outside the US, and I think brief info like this would spread the word. Likewise the next sentence -- I think it's important to make it clear where we know the file is in the PD and it's caveat emptor anywhere else.
It's rather nuanced, so I'm sure a few more iterations will be for the best. -- SCHolar44 (talk) 01:33, 10 August 2021 (UTC)
In accord with the philosophy of continual improvement, I added some amended wording (above, under orange notes) to shorten and simplify.SCHolar44 (talk) 03:53, 11 August 2021 (UTC)

┌─────────┘
@Mysterymanblue, MGA73, Nosferattus, Ghouston, Gestumblindi, Donald Trung: Mindful that as discussed earlier on the {{PD-because}} Talk page, we are trying to rectify an addition to this template that was made erroneously 9 years ago without any discussion or support, I'm keen to keep Mysterymanblue's proposal going. We have only three Supports so far. MGA73, Nosferattus, Ghouston and Donald Trung, given the discussion and modifications made, do you feel free to support now? This is where we are:

PD-icon.svg
This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Dialog-warning.svg This template must not be used for an uploader's own work. Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}} for a public domain dedication.

If this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain in the U.S. In other jurisdictions, copyright law may restrict re-use of this content.

If we end up with seven "Supports", will that be enough? (I don't have experience with management of proposals). If not, should we be asking editors in related Talk page discussions to take a look?  — SCHolar44 (talk) 09:34, 22 August 2021 (UTC)

@SCHolar44: Are there any reasons to keep the template? I think the template is a bit like {{PD}}. If you pick 5 random files from Category:PD other reasons then we could try to see if we can't find a better template or if the file has to be deleted. If we can find a better template then we should perhaps do that. If not then changing the text could be okay. --MGA73 (talk) 10:16, 22 August 2021 (UTC)
@MGA73: Every household has a junk drawer (or something similar) where everything without a place goes. PD-because is our junk drawer. I agree that the junk drawer is not the best and that it should be cleaned out. But even if you take the time to organize everything in the junk drawer, you still need a junk drawer because new stuff is constantly coming into your house, and it often can't be put in its right place right away. If you get rid of the junk drawer, the junk will pile up all over the house, and that's not something anyone wants.  Mysterymanblue  17:16, 22 August 2021 (UTC)
@Mysterymanblue: Lol. Yeah we all have a junk drawer :-) But if we are organized we could say no to junk. If new files can't use an existing template then perhaps it is safer to delete it. Are there any other reasons for a file to be PD than 1) It is not eligible for copyright, 2) The author released the file to PD or 3) The copyright have expired? --MGA73 (talk) 18:57, 22 August 2021 (UTC)
@SCHolar44: Apologies for not getting back to you sooner—I have been a bit busy IRL. While I greatly appreciate the work you've done on the proposal, I still don't see a reason to include the phrase "If this work did not originate in the United States" as part of the disclaimer. Every work on Commons must provide an explanation for free use that is valid in the United States. The provision of such an explanation is not based on the work being or not being a U.S. work. So phrasing that part as an if-then statement does not make sense because it must be provided 100% of the time. I am also concerned that the phrase "In other jurisdictions, copyright law may restrict re-use of this content." may cause people to believe that they do not need to provide an explanation for why the work is in the public domain in the country of origin (since that could conceivably be part of "other jurisdictions"). Perhaps a better wording would be "Even if this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain in the U.S. and its country of origin. In other jurisdictions, copyright law may restrict re-use of this content." :Even still, I am weary to include such a statement on having a U.S. explanation because there are a few edge cases. What if the work is public domain in the country of origin but under a free license in the U.S.? What if they have a country of origin explanation in PD-because and explain via a separate license tag why the work is freely usable in the U.S.? The statement should either be very general to cover these cases or it should not be included at all, in accordance with most copyright templates that are not specific to any one country.
I also don't really understand why we need to keep the other PD-self templates around. You say you want to give guidance to newcomers, and that is admirable, but I don't see how giving them multiple option, some of them far worse than others, advances that goal. There are essentially no advantages to using anything other than CC0 because the alternatives are invariably more legally vague. Mentioning these other PD-self templates in the template both makes the template longer than it needs to be and suggests that we have equal preference toward these different styles of PD dedication (we don't.)  Mysterymanblue  17:01, 22 August 2021 (UTC)
@SCHolar44: I'm afraid I don't really understand the part that reads "Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}}" {{PD-self-CC0}} isn't a template, and I have no idea what "alternatives in the {{PD-self}} template" refers to. Why don't we just write: "Instead, use {{self|CC0}} or {{PD-self}}." That's much clearer. Nosferattus (talk) 17:11, 22 August 2021 (UTC)

┌─────────┘
@Mysterymanblue, MGA73, Nosferattus, Ghouston, Gestumblindi, Donald Trung:
Dear colleagues,
Thank you for your feedback. Although I'm an experienced professional policy developer, my familiarity with the variety of copyright contexts you've mentioned is quite limited, so I very much appreciate learning about them.

Need for the template
MGA73, you commented, "If new files can't use an existing template then perhaps it is safer to delete it. Are there any other reasons for a file to be PD than 1) It is not eligible for copyright, 2) The author released the file to PD or 3) The copyright have expired?

– The problem is that there are not enough templates available to cover all PD possibilities in non-US jurisdictions. I have encountered solid resistance to developing additional ones or even updating outdated ones (PD-Australia, for example, is now factually incorrect; three templates, each dealing with specific policies, are an obvious solution but I don't believe it will come soon, if ever). Conclusion for the time being: until all situations are covered by a template, we need a catch-all.

"If this work did not originate in the United States"
Mysterymanblue, you commented, "I still don't see a reason to include [this] phrase as part of the disclaimer".

– I can see the weakness in the wording. Taking your point that every work on Commons must provide an explanation for free use that is valid in the United States and that wording needs to be very general to cover these cases, how about this, then? (it combines your better words with mention of why the US jurisdiction is important):
Since Wikimedia Commons servers are located in the United States, if this template involves a non-U.S. jurisdiction it must be accompanied by a justification for free use that is valid in the U.S.

Don't give them multiple options
I've implemented the comments of Mysterymanblue and Nosferattus: only CC0 is mentioned now. I've also deleted mention of other jurisdictions.

PD-icon.svg
This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Dialog-warning.svg This template must not be used to dedicate an uploader's own work to the public domain; CC0 should be used.

Since Wikimedia Commons servers are located in the United States, if this template involves a non-U.S. jurisdiction it must be accompanied by a justification for free use that is valid in the U.S.

I hope I've fully taken your comments on board. If not, I'm listening.  :-)  — SCHolar44 (talk) 06:53, 26 August 2021 (UTC)

I think this most recent proposal is perfectly fine, simple and clear; therefore, I Symbol support vote.svg Support it. Gestumblindi (talk) 10:00, 26 August 2021 (UTC)
Symbol support vote.svg Support SCHolar44's wording of 06:53, 26 August 2021 (UTC).   — Jeff G. please ping or talk to me 11:49, 26 August 2021 (UTC)
Symbol support vote.svg Support the latest wording. Nice work. Nosferattus (talk) 12:05, 26 August 2021 (UTC)

An edit rquest has now been made at Template talk:PD-because. SCHolar44 (talk) 08:15, 9 September 2021 (UTC)

Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons[edit]

Recently there was a discussion about fantasy flags generated by users from the Commonswiki being used on other Wikimedia websites and the potential anti-educational effects that these fantasy flags could have on their readers. Meanwhile on Wikimedia Commons we have many tags like "{{Fact disputed}}", "{{Fictional flag}}", "{{Disputed coat of arms}}", "{{Fake sports logo}}", "{{Fictitious map}}", Etc. to convey the message that these files should not be used in a context that make them seem official, many such images still are used on a large number of Wikimedia websites that have reliability issues because nobody is ever notified of them.

Therefore I would like to propose a bot to operate globally and notify any Wikimedia website when a fact has been called into dispute like when an image gets nominated for deletion now or tagged as "Speedy", in order to prevent vandals from tagging all images with such tags the bot would have to wait 24 (twenty-four) hours or 48 (forty-eight) hours before notifying other communities. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:09, 4 August 2021 (UTC)

Votes (Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons)[edit]

  • Symbol support vote.svg Support, as proposer. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:05, 1 August 2021 (UTC)
  • Symbol support vote.svg Support However, I think the proposal is too brief and implementation would be hard. There's a lot of history under this and misleading images of many types are an extremely easy way to misuse Commons and deliberately corrupt the educational value of other projects under the false assertion that it protects "free speech" or that the project is not censored. This misuse happens and has been allowed to happen since the project was created. -- (talk) 10:02, 4 August 2021 (UTC)
  • Symbol support vote.svg Support - would go a long way to stopping image misuse.  Mysterymanblue  15:14, 4 August 2021 (UTC)
Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 14:29, 6 August 2021 (UTC)
  • Weak oppose, while the underlying idea is good, there are too many grey areas and too much potential for such a system to be abused. People already misuse these templates for political and ideological disagreements, and I fear this would exacerbate that. Nosferattus (talk) 17:16, 8 August 2021 (UTC)
  • Symbol support vote.svg Support can avoid any files that are possibly out of scope. --A1Cafel (talk) 10:00, 14 August 2021 (UTC)
  • Symbol support vote.svg Support it is common for media to get used across projects, only for years later to be identified as inaccurate or fan-made.--BevinKacon (talk) 12:44, 14 August 2021 (UTC)
  • Symbol support vote.svg Support - We already have a bot that adds file copyvio/DR notices to Wikipedia talkpages and that works fine so can't see why this can't too. Unfortunately it will be open to abuse and people will abuse it but at the end of the day unless anyone above has a better solution than I fully support this. –Davey2010Talk 22:18, 14 August 2021 (UTC)
    @Davey2010: This functionality is not in that bot's approved scope or programming.   — Jeff G. please ping or talk to me 11:46, 15 August 2021 (UTC)
  • Apologies if this sounds arguementitive or rude certainly not my intention but I never said it was ?, I said we have a bot that does a similar sort of thing :), Thanks, –Davey2010Talk 12:14, 15 August 2021 (UTC)
    @Davey2010: No, you didn't, and I'm sorry if in replying to you I implied that you wrote that it was. But logically, a next step could be NRodriguez (WMF) or her team planning to modify Community Tech bot or creating another bot with similar code to do this, and I wanted to publicly make sure the community in general and each wiki community approved such before implementation.   — Jeff G. please ping or talk to me 13:19, 15 August 2021 (UTC)
Hi Jeff, No worries, Happy editing my friend, Take care, –Davey2010Talk 14:22, 15 August 2021 (UTC)

Discussion (Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons)[edit]

  • Pictogram voting comment.svg Some clarification, my personal stance on fantasy bullshit is that they should be included in Wikimedia Commons as more often than not they do have an educational value as often they are based on common misconceptions, incomplete information, misinformation that might have been spread by credible sources like museums and universities (you would be surprised how much bullshit you can find in otherwise "academic" papers simply because the person in question used the wrong sources) and I believe that such things can be used to contrast real Vs. fake and just discuss the meta-history of a subject and its historiography. That aside bullshit becomes misinformation when it's presented as real information. We can have a projection of a pear-shaped earth or a velociraptor-shaped earth, but while an image of a velociraptor-shaped earth can illustrate the beliefs of the Dinosaur Earth Society the same image would be horrible misinformation on any serious article about the geography of the planet Earth.
As the hypothetical bot will most likely notify all talk pages indiscriminately about the tagging it is up to the editors of that particular Wikimedia wiki to decide to remove/replace it or keep it, an article about flag proposals can have images of flag proposals, an article about bullshit land claims can have fake maps, an article about fictional sports teams can have fictional sports logos, Etc. The bot clearly can't differentiate if an image is where it should be, however, it could notify users.
Personally I would have preferred the Community-Tech-Bot to do these notifications but as I am permanently banned from the Meta-Wiki and any time I try to appeal that ban a user that hates me denies the appeal and comments how I should have my talked page access revoked so "I won't waste their time anymore" I can't exactly propose anything at the global tech wishlist and unfortunately there isn't a localised Wikimedia Commons annual tech wishlist, though if it is possible I would like to petition Wikimedia Deutschland (WMDE) to get more involved here and create a "Commonswiki Tech Wishlist" where they would fulfill 5 (five) instead of 10 (ten) "community wishes", but I have no idea if it would be possible to convince Wikimedia Deutschland (WMDE) of doing something like that, so I hope that someone that operates a global bot can pick this request up if there is consensus for it.
Regarding potential vandalism, generally speaking files are patrolled and personally I am more inclined towards a 24 (twenty-four) hour window so other Wikimedia websites are more quickly notified about potential reliability issues, if someone raises an issue about fantasy maps being used at the Indonesian-language Wikipedia that map can still continue to be used at the Wolof-language Wikipedia because nobody is notified of its factual inaccuracies, this bot should solve this issue by not letting such discussions "stay in the talk pages of only one wiki".
A big issue this might create is hypercorrection where a user challenges a claim that later turns out to be correct and other Wikimedia websites will remove all references to that media file, but of course the best action to take here is provide reliable sources and restore it where the user can. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:09, 4 August 2021 (UTC)
  • I think we cannot order anybody to provide such a bot, and we cannot replace any (global or local) bot approval by this discussion. What will be the actual result if this proposal is accepted? --Krd 10:08, 4 August 2021 (UTC)
    I think voting on the principle is fine. As an example, if there was funding for a group-run bot based on consensus, I'd be happy to be paid a small honorarium to write the main code for it and others can operate it, i.e. a teeny fraction of the cost of getting WMF dev to do anything. It would be reasonable for sister projects to opt out of it, but we are only talking about leaving advisory notes on talk pages. BTW, the example of images up for deletion is a bad one, there is already a bot that does this for DRs on images in use in articles on some wikipedias. -- (talk) 10:36, 4 August 2021 (UTC)
    @Krd:, you are right, we can't force anyone to do this, but it would show that there is at least some consensus for this, as "fake information" is rampant and quite recently there were Administrators' Noticeboard and Village Pump discussions about fantasy flags being used on Wikipedia's. We already have a bot for deletion notifications, so this is "the same in spirit". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:23, 4 August 2021 (UTC)
    I'm not opposed at all, I just think it's an unconventional approach. Wouldn't it be better to first find a bot operator who is willing to do it, and then just do it as a nobrainer, instead of making this formal proposal? I mean if there is nobody who does it, the whole story here appears quite pointless for me. Speaking as a bot operator, I would prefer to be asked over being requested to implement what is already decided. Also I think it's better to take into account the needs of the individual projects the bot shall run on, instead of making decisions here for all projects of their heads. Even if that's fair from our point of view, I'm quite sure communities will think different. But, that's just my 2¢, maybe I'm mistaken. --Krd 16:13, 4 August 2021 (UTC)
  • Deletions are flagged on the talk: page, because they're mostly of interest to article maintainers, who can be expected to know about talk: pages. But if the issue is accuracy, then that would presumably need to go on the main page, where all readers would be informed of it. That's a riskier slot, bearing in mind potential for misuse.
There's also the issue of "fictional" flags. Why are these "inaccurate"? If the flag is a fiction, then what's the reality and why don't we use that instead? We might use this for inaccurately-drawn flags (such as edit-warring over the proportions of a real flag), but if a flag is fictional then it either doesn't belong on a page describing reality, it does belong on a page describing that fiction, or it would belong on a page describing hypothetical flags, such as a British flag without a now-independent Scotland. None of which are "inaccuracies" deserving this sort of flagging. Andy Dingley (talk) 13:11, 4 August 2021 (UTC)
It is best to use talk pages because in general people don't want casual readers to see "editor" things. A fantasy flag that is correctly used as a fantasy for a fantastic location is fine, but there are examples where flags with disputed origins are attributed to historical entities. If an issue exists with the content of an article (and media files are article content) then it is up to the regulars to fix it, in some cases Wikimedia Commons "has decided for projects" by deleting files as "fake" that later turned out to be true. Having more eyes on an issue causes more experts to be able to correct any issues. The bot should only indicate that issues have been raised, not that the flag itself is fake, perhaps we can create specific templates for proposed flags that are not "fantasies". For example an alleged flag of a historical province of France that turns out to be a later invention is a "fantasy flag" but not a proposed flag. A specific template for "Proposed flag" should get rid of such things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:42, 4 August 2021 (UTC)
  • @:, if you think that the proposal is too short I give you my written permission to adjust it however you see fit, as long as the basic premise (a bot notifying sister projects about reliability issues on Wikimedia Commons and a short window to fight vandalism here) remains the same. I deliberately kept it short because earlier this year I had a large batch of proposals that were ignored (had little engagement) because they were too long and spitting them had little engagement despite being things that are all already the standard on the English-language Wikipedia. So I kept this proposal short and to the point to avoid this with some notes below. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:31, 4 August 2021 (UTC)
  • I think this proposal would do quite a bit to stop image misuse, assuming that Wikipedias would implement its suggestions. I have gone and removed images of fictitious flags from several Wikipedias where they were used erroneously (all in cases where people assumed an entity that didn't have a flag had a flag). I dislike doing this in general because it sometimes looks like I am vandalizing the page because I am unable to provide a cogent explanation in the source language. I hope implementing this proposal would empower these Wikis to seek out and snuff out disinformation on their own terms. Another way to reduce file misuse would be to require fictitious flag file pages to clearly and unambiguously identify themselves as fictitious in their titles, possibly as the first word. This would hopefully prevent people from missing the file page disclaimer by making it an integral part of how the file is used.  Mysterymanblue  15:42, 4 August 2021 (UTC)
I like this non-technical solution. If this proposal could be read as a policy to force the first word in a filename to be on an agreed list of red-flag words like Fictitious, Propaganda or Misleading, this might be enough to get Wikipedias to pay more attention. -- (talk) 15:59, 4 August 2021 (UTC)
  • What about instead of automating the notifications of the wikis, the bot instead lists all globally used files that have those templates in a subpage? The notification (or correction if necessary and possible) will have to be done manually by a human instead. I'm not really a fan of automating the notifications to each wiki since I feel it could lead to misunderstandings. I think the notifications should be done by a volunteer familiar with the wiki involved. pandakekok9 12:10, 14 August 2021 (UTC)
    @Pandakekok9: Where would that subpage be? What would it be named? What would be on it? Who would pay attention to it?   — Jeff G. please ping or talk to me 16:29, 14 August 2021 (UTC)

Maps[edit]

A map, in particular, being "disputed" does not mean it is wrong. For example, consider Israel/Palestine. Is all of Jerusalem part of Israel? Is the Golan Heights? Is it OK to show where the 1967 border was on a present-day map? Is it OK to color the West Bank and Gaza two different colors? Is it OK to refer to "the West Bank" (vs. "Judea and Samaria")? etc., and that is not even taking into account some more extreme views on either side. Any map of the area will be disputed by someone, but that does not mean it is wrong, just that any given Wikipedia ought to be clear whose view of the matter it represents.

Similarly for political maps of a dozen other places in the world, not to mention almost any map about linguistic distribution. - Jmabel ! talk 23:02, 4 August 2021 (UTC)

Indeed.
But using any of these maps, an editor should be aware of its controversial nature and carefully choose among the available versions, or abstain from using one if none was appropriate. I don't think a comment on the talk page is overkill. In many cases, the editors were already aware of the controversy, but a bot notifying that the map has been marked as disputed is no worse than an IP editor popping up arguing that all the area should be shown as integral parts of India/Israel/Ukraine/whatever, and we do handle that just fine on the Wikipedias. Just make the note clear, and avoid spamming the talk pages.
LPfi (talk) 09:38, 7 August 2021 (UTC)
We could easily create a warning template called "{{Disputed map}}" (apparently already exists) and / or a more general "{{Politically sensitive}}" explaining about why the file can be perceived as "offensive" or "partisan" as the Wikimedia Commons doesn't have a NPOV. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:17, 4 September 2021 (UTC)

Truth in file naming for symbols[edit]

Proposal[edit]

Approve the following as a part of the file naming/renaming guidelines, and broadly permit its use as a rationale for rename requests:

Logos, trademarks, flags, insignia, emblems, seals, coats of arms, and certain other symbols serve the purpose of distinctively representing entities, groups of people, and ideas. A file on Wikimedia Commons may only purport to be one of these symbols without qualification if:

  • Accuracy: The file accurately depicts the symbol;
  • Reality: The symbolized entity, idea, or group of people exists or has existed in the real world, within a reasonably well-known work of fiction, or within the scope of a Wikimedia project; and
  • Usage: The symbol has commonly or officially been used to represent the entity, idea, or group of people within the appropriate context.

If a file depicting a symbol fails on any of these three criteria, the top of its description page and the beginning of its name must contain a qualification clearly marking on what grounds it has failed. For example:

  • A logo is used by the TV show Black Mirror, but its representation on Commons incorrectly reflects certain parts of the graphic design. This file fails the accuracy criterion. An appropriate name is "Inaccurate Black Mirror logo".
  • A user creates a seal for the fictional Republic of Wikanistan and uploads it to Wikimedia Commons. This file fails the reality criterion. An appropriate name is "(Fictional) Flag of the Republic of Wikanistan".
  • The city of Provo, Utah, holds a flag design contest. Jane Doe designs a flag, submits it to the contest, and uploads it to Wikimedia Commons. It does not win. This file fails the usage criterion. An appropriate name is "Jane Doe's proposed flag of Provo, Utah".
  • A user uploads an alternative flag of the State of Deseret that was never in use. This file fails the usage criterion. An appropriate name is "Fictitious flag of the State of Deseret".
  • A user uploads a flag purported to represent Uzbek-Laotians. There are no sources, reliable or otherwise, that substantiate this usage, so the file fails the usage criterion. An appropriate name is "Proposed flag of Uzbek-Laotians".

The qualification does not have to take a standard form and may vary between files, even in similar situations. The specific circumstances of each case should be taken into consideration, and—as usual—the suggestion made by this guideline for certain files may be overridden if consensus finds a compelling reason to do so.

Explanation[edit]

There has been much ado about the use of fictional/fictitious/fantasy symbols on Commons recently; see Commons:Village pump/Archive/2021/07#Discussion of fictional flags and of deleting files in use and Commons:Administrators' noticeboard/Archive 85#Fictional flags - are they in scope?. This proposal seeks to remedy some (but certainly not all) of the issues with the misuse of such symbols.

This proposal should not be construed as implicitly allowing or disallowing such symbols on Commons; it is scope neutral. It should also not be seen as an alternative to Donald Trung's notification proposal above. While the two proposals are related, they don’t really get in each other’s way, so an entirely separate discussion is warranted.

The purpose of requiring the qualification be first in the file name is to make the potential issues with using such symbols unignorable. This requirement may be removed from the proposal if the discussion below is against it.

Polling (Truth in file naming for symbols)[edit]

Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 14:25, 6 August 2021 (UTC)
  • Symbol support vote.svg Support, this is more of problem for non-fiction works. Will reduce risk of accidental usage on other wikis.--BevinKacon (talk) 11:17, 7 August 2021 (UTC)
  • Symbol support vote.svg Support - It's basic common sense - I've uploaded lookalike logos and "lookalike" is stated in the titles although bizarrely having looked at File:Dailymail logo lookalike.png the file is being used virtually everywhere .... but that's not my problem as I've stated "lookalike"..., If a logo is fake then it should be stated in some way, –Davey2010Talk 11:39, 7 August 2021 (UTC)
  • Symbol support vote.svg Support, I actually proposed this during the original village pump discussion and Mysterymanblue called it a good idea then, I actually was planning on proposing this before thinking up the bot notification because of a number of faults with this, for one flags, coats of arms, and maps of fictional places that are exclusively fictional (like Mordor or 1984's Eastasia) probably shouldn't need this as it's "excessive". Furthermore, this year I managed to get a file undeleted uploaded by the Globally Locked Sockmaster Musée Annam undeleted by saying that I will rename it to "fake flag", later during my research I discovered that the flag was actually legitimate. The problem with this proposal is that in fighting misinformation we might spread more misinformation, but weighing these the benefits far outweigh the deficits and redirects should preferably be kept. This policy should be enforced like tagging a "disputed file" and all parties should use as much reliable sources as possible to construct their claims. This should essentially be the [CITATION NEEDED] for disputes and the "Fake news" tag for clear fantasies with educational value. Proposed flags should probably better be called "proposed" and not "fictitious". In a nutshell, this proposal just raises our standards for sourcing, which is a good thing (as I believe that we shouldn't have notability standards, but have reliability standards and point out false information rather than delete it). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:08, 8 August 2021 (UTC)
  • Symbol oppose vote.svg Oppose - I think this would be substantially disruptive and lead to countless edit and move wars. Traditionally, Commons has not been an arbitor of "truth". Instead we are just a neutral file host, which is why we don't have tons of edit wars despite the added complication of being a multi-lingual and multi-cultural project. There are way too many hotly disputed grey areas around "truth" when it comes to things like flags, maps, and national and ethnic symbols, which are all really just shared fictions anyway. There's also the fact that some cultures have no official governments or nations and thus it is hard to prove their "truth", for example, Native American cultures or the Kurdish culture. In fact, we might inadvertently contribute to their erasure with such stringent demands for verification. At the very least, we would be exacerbating existing biases about how different groups are represented on the internet, as whoever has the most digitized sources to back up their claims (i.e. rich, Western cultures) will get to decide what "truth" is. If we are going to start arbitrating truth, we need to be a lot more thoughtful about how we are going to handle biases, disputes, and grey areas, as this is opening up a huge can of worms. Nosferattus (talk) 17:49, 8 August 2021 (UTC)
  • Symbol oppose vote.svg Oppose I am with Nosferattus here. This kind of judgment is better left to the final user, and there are subjects where "truth" is very relative. E.g. in the field of heraldry, there is no one true depiction of a coat of arms. All that needs to be met is the so-called blazon, i.e. the heraldic description of the elements included in the coat of arms. The depiction, however, is then left to any artist and their fantasy. So if we introduce a truth check like proposed above, I can foresee countless bickerings and edit wars about how one heraldic element is not truly a lion but rather a leopard or something totally different, and some such. The same goes for common symbols like exit signs, hazard warnings, etc. I fear that we would then see a flood of DRs concerning the lengths, widths and colour hues of allegedly non-officially drawn symbols. This wouldn't be helpful at all and I don't think it is Common's task to take over the editor role for the media content of other Wikimedia projects. We do already have procedures to counter obvious fakes and out-of-scope content, so I don't see a need to enforce the rules for symbols. De728631 (talk) 18:25, 8 August 2021 (UTC)
  • Symbol oppose vote.svg Oppose: this proposal puts far too much burden on filenames to provide qualifying details. Beside its likelihood of creating new battlefields, I can see it also leading to ever-lengthening names. Sourcing, purpose, relevance, accuracy, and so on are best communicated through descriptions and categorization. (I mostly avert my eyes from the Structured Data myself, but I suppose that too.) Filenames that are distinctly misleading, for example the Jane Doe above’s Official Flag of Provo, Utah, can already be changed under the existing criteria. I would be all in favour of expanding our suite of problem templates or of taking other measures to prominently highlight more specific issues with user-created, inaccurate, or biased content, but filenames are not an appropriate means to do so.—Odysseus1479 (talk) 20:01, 22 August 2021 (UTC)
  • Symbol oppose vote.svg Oppose as against the spirit of COM:NPOV. The goal of Commons should not be to make a determination of fact. -- King of ♥ 20:10, 22 August 2021 (UTC)

Discussion (Truth in file naming for symbols)[edit]

I already left some reasons above, but to add an addendum, I believe that this will have a similar effect on Wikipedia's and will invite more conversation and sourcing here. The problem with fantasies is always bad and / or biased sourcing. Unfortunately, sometimes high quality sources may spread misinformation so discussions should take place over direct deletion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:10, 8 August 2021 (UTC)

@Donald Trung: Thank you for bringing up this idea in early discussions over this issue. I agree with your comment above that the flags of some entirely fictional places do not require the qualification: that's why the proposal allows for symbols of entities that exist "within a reasonably well-known work of fiction" to satisfy the reality criterion. So, for example, an accurate depiction of the flag of Panem (used in the Hunger Games movie) would satisfy the accuracy criterion for correctly depicting the symbol, the reality criterion for being used in a reasonably well known work of fiction, and the usage criterion for having been "officially been used" to represent the fictional country in the appropriate context (works of fiction are authoritative on their own depicted symbols). This proposal would not require a qualification for such a flag, though clarification could always be provided if it would make the file better. Fan-made symbols from a fictional work would require a qualification because such symbols are generally not "officially or commonly" used, and symbols from essentially unknown sources (e.g. self-published stories by Wikimedia users) would also require a qualification.  Mysterymanblue  18:17, 8 August 2021 (UTC)

@Nosferattus: Hi, thanks for your concern above. The proposal tries to deal with the issue of some symbols not being officially recognized by expressly allowing commonly used symbols to pass the usage criterion. Do you have a specific file in mind that you think might be an issue?  Mysterymanblue  18:18, 8 August 2021 (UTC)

@Mysterymanblue: No I don't have a specific file in mind, but it's not hard to imagine such scenarios. Even in cases that should be relatively straightforward, it's often difficult to define what is "official" or "common". As one example, until 2019, the country of Belize had no standardized flag. Implementations varied widely and the most commonly seen version within Belize was ironically the one from Wikipedia. Thus Commons actually created the "truth" rather than reflecting it. And that was a situation that didn't involve any politics, nationalism, wars, disputed borders, governments in exile, ethnic cleansing, historical erasure, or genocide. I think we should leave such disputes to the Wikipedias rather than bringing them to Commons. That said, I would be much less opposed to a proposal that simply provided guidance for case-by-case discussions rather than implementing hard rules. Nosferattus (talk) 18:57, 8 August 2021 (UTC)
@Nosferattus: My main concern with forcing discussion in all cases is that most people would agree that most of these fictional symbols should have a warning on them, so forcing discussion in every single case would put needless strain on the community's limited resources. Would you be more likely to support a proposal that expressly stated that 1) renaming under the proposal should only be taken without discussion when the file obviously and uncontroversially fails at least one of the criteria, and 2) there may be cases where there are multiple accurate depictions of a symbol or multiple symbols used to represent an entity, idea, or group of people.  Mysterymanblue  19:52, 8 August 2021 (UTC)
@Mysterymanblue: The problem is, unlike for text, it is rather difficult for one person to tell what is actually a common version of a symbol, especially when you are dealing with unofficial, non-standardized symbols. Perhaps the burden of proof should be switched. How about something like: In cases where a logo, flag, insignia, emblem or other symbol representing an entity or group of people has an official status (for example, in law or as a trademark), depictions of that symbol must be accurate (per the laws or trademark), or else the file name and description page must include a disclaimer. That would solve the most obvious cases without creating a battleground for the fuzzier cases. Nosferattus (talk) 21:24, 8 August 2021 (UTC)

Link to COM:FT in Upload Wizard[edit]

I was about to upload a new file to Commons and noticed that the Upload Wizard's start page says nothing about file types. It would be quite useful to have a link to Commons:File types inserted at Template:Upload Help notice. —capmo (talk) 14:43, 20 August 2021 (UTC)

@capmo: That makes sense, but begs the question: what type of page is Commons:File types supposed to be? It does not claim to be policy, guideline, or essay.   — Jeff G. please ping or talk to me 01:53, 23 August 2021 (UTC)
Commons has a lot of informational pages, like Commons:Copyright rules by territory and its subpages. They are simply meant to provide facts and don't really fall into the "community consensus" hierarchy. -- King of ♥ 01:57, 23 August 2021 (UTC)

HOW-TOs or Use-Case Recipes[edit]

JPEG image Lossless Transform is a HOW-TO I made on lossless JPEG DIY rotate mirror flip spin crop. Comments? Is there a wiki Namespace to search for articles like this? .... 0mtwb9gd5wx (talk) 13:46, 2 September 2021 (UTC)

There is the "Help:" wikispace, I am not sure if it's the best match but it sounds like it would fit there. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:39, 3 September 2021 (UTC)

Template:Spa[edit]

Once upon a time, there was a template {{Spa}}. Like en:Template:spa, it was used to tag single-purpose accounts. See Commons:Deletion_requests/File:Abdullah_Öcalan.png as to why we need this.

In 2011, it was repurposed by @Vincent Steenberg: to point instead to a small town in Belgium. I have no idea why, if this was discussed anywhere, or why Commons would need such a thing.

I propose to revert this. Andy Dingley (talk) 01:28, 10 September 2021 (UTC)

We have a lot of these: Category:Multilingual tags: Locations by country. --El Grafo (talk) 06:55, 10 September 2021 (UTC)
This template is being used 169 times. Use Template:Single-purpose account instead. Vincent Steenberg (talk) 07:32, 10 September 2021 (UTC)
Hold on, if you give me 20 minutes, I will free up this template. Vincent Steenberg (talk) 13:23, 10 September 2021 (UTC)
✓ Done I renamed {{Spa}} to {{Spa, Belgium}}. You can now restore the first the way it was 13 years ago. Regards, Vincent Steenberg (talk) 13:35, 10 September 2021 (UTC)
  • Thank you Andy Dingley for noticing this - I was going to use the SPA template for a DR only to find it didn't apparently exist, If we can put SPA back into existence that would be grand :), –Davey2010Talk 15:25, 10 September 2021 (UTC)

Encourage uploaders to use compression for TIFF format?[edit]

Hi,

I happened to run into a few TIFF uploads. They are sometimes relatively large batches of large files (100-200MB), and even if Mediawiki creates jpeg thumbnails of them, I wonder what's the advantage of those large files? I am all for keeping the original files (The files can be as large as they have to, if they need it), specially for things like donated collections, but just by using TIFF compression to the original uncompressed TIFFs, I was able to make the file size 5 times smaller with lossless compression (identical file printed on screen, will never degrade, no matter how many times is re-saved), keeping the metadata and file format. Patents for compression no longer apply. The compression is so low resource intensive (compared to JPEG), that it won't have any issues being opened in old phones or computers. But the original file size may have issues being opened due to higher memory requirements. I think the TIFF format that was used in those cases, even things like "Library of congress" was whatever came out of the scanner software, without many regards for practical usage/reuse. Even Mediawiki software sometimes has issues creating thumbnails of those very large files: https://phabricator.wikimedia.org/T290462

My questions is, other than "keeping the original files intact", would it make sense to recommend to use compression on large TIFFs on the File formats page? I think it will make life easier for the uploader (5x speed on uploading), the software and the reuser/downloader. Am I missing something I am not thinking about? I am not suggesting to enforce this, I think it is not super-important for/on occasional uploads/occasional TIFF contributors, but may make things faster/easier for large batch uploads (converting things losslessly, on the fly before uploading)? --jynus (talk) 10:32, 14 September 2021 (UTC)

Uncompressed TIFF is a library standard. There's not much of a reason to upload TIFF besides keeping the original files intact.--Prosfilaes (talk) 23:27, 14 September 2021 (UTC)