Commons talk:Overwriting existing files

Archives 1, 2, 3

See Archive 1 for the RFC establishing COM:OVERWRITE as guideline. This is the talk page about this guideline. Please use the upload help or a help desk in your language for questions about its application.

Template for historic static maps?

Hi, I've just created a new .svg version for an old .png map I made in 2018. The new .svg map is meant to be updatable if new information changes the situation, and I encourage people to update it with the Template:Current. I would like to keep the old .png version as a static map, to show the historical situation as of 2018 (when I created it). Minor corrections are still okay, as long as they reflect the historical situation as of 2018. Is there an equivalent of Template:Current that I can use to say something like 'This is a static map. Please keep this file to reflect the historical situation as of 2018'? None of the templates in Category:Dont overwrite-file templates are really what I'm looking for, they are too strict for my purposes. Thoughts, anyone? Nederlandse Leeuw (talk) 14:39, 30 May 2023 (UTC)

@Nederlandse Leeuw: I've just created this template for that purpose. MGeog2022 (talk) 20:03, 27 July 2023 (UTC)

Thank you! Nederlandse Leeuw (talk) 23:51, 27 July 2023 (UTC)

@Nederlandse Leeuw: You're welcome. But there's a small problem with the new template. Files where the template is used, are being shown as belonging to "Category:Dont overwrite-file templates" (where the template itself belongs). That doesn't happen with files using any other of the templates belonging to same category. It's driving me crazy. I asked for help at Help Desk, but have no answers yet; I'll ask it again. MGeog2022 (talk) 11:41, 28 July 2023 (UTC)

@Nederlandse Leeuw, the problem is fully fixed now, thanks to Help Desk's help. You can use the template without worry. MGeog2022 (talk) 12:46, 28 July 2023 (UTC)

@MGeog2022 Thanks! I've added it to Commons:Evidence-based mapping#Commons tools. Cheers, Nederlandse Leeuw (talk) 15:36, 28 July 2023 (UTC)

Policy change should be reverted

This policy change is the antithesis of how Wikipedia operates. Requiring every edit of an image to be approved completely breaks the flow of updating images on Wikipedia. I'll be advocating that any image NOT be uploaded to Wikimedia commons in the future in order to prevent this policy messing with the ability to improve and update Wikipedia articles. It will also put a lot of strain on Wikimedia servers by creating tremendous amounts of duplication as users instead opt to re-upload images rather than replace them, and manually edit them into every Wikipedia language page where they are used. This was poorly thought out and completely inane. Ergzay (talk) 01:20, 4 November 2023 (UTC)

@Ergzay: Where were you when the discussion archived at Commons:Village pump/Proposals/Archive/2023/08#Limit file overwriting to users with autopatrol rights was happening?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 04:23, 4 November 2023 (UTC)

@Jeff G. Obviously not there because I had no way of knowing about it, as is probably the case of the huge majority of users across all of Wikipedia that this ridiculous policy effects. Ergzay (talk) 01:36, 5 November 2023 (UTC)

@Ergzay: If you were following COM:VPP or COM:CD, you should have known about it.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 11:05, 5 November 2023 (UTC)

Given it's the first time I've heard of either of those, that doesn't really help either. Ergzay (talk) 04:35, 6 November 2023 (UTC)

@Ergzay: COM:VPP is the "Proposals" link on the Commons:Discussion pages sidebar on our Help desk and Village pump. It saddens me that you missed it.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 10:01, 6 November 2023 (UTC)

I'm an editor. I don't dive into multiple levels of submenus and internal politicking that I have no care to get involved with. It's only when people try and lord over the rest of the editors, like as has been done here, that I'll comment in this sort of place. I'm sure that's the case for the vast majority of people. Ergzay (talk) 19:10, 9 November 2023 (UTC)

Personally I don't think this will last long, as soon as @GPSLeo gets tired of his new full time job over at Commons:Overwriting_existing_files/requests the policy will get changed. Ergzay (talk) 19:12, 9 November 2023 (UTC)

@Jeff G. Also if the admins are going to make this type of massive change, they should advertise it on the top of every language Wikipage in a big banner. This affects literally everyone on the entire site of every language. A private, quite hidden, discussion of a couple dozen people changed very basic policy for hundreds of thousands of people. Ergzay (talk) 19:20, 9 November 2023 (UTC)

@Ergzay: Every page on this project has a link to Village pump; this change was by no means hidden. Go ahead and craft the big banner you want, in hundreds of language versions, then see if you can get it accepted "on the top of every language Wikipage". Of course, it may get rejected because it is too big.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 12:06, 11 November 2023 (UTC)

This almost sounds like you're saying "it's too much effort to do such a big change properly, so lets push it through anyway"... Ergzay (talk) 16:59, 11 November 2023 (UTC)

Most images should not be overwritten, so this policy makes a lot of sense. Yann (talk) 09:08, 4 November 2023 (UTC)

@Yann Many images commonly require updating regularly, especially things like maps which are now all effectively frozen because most users won't go to the trouble of jumping through hoops just to update them, causing them all to go further and further out of date. Also things like fixing images that were poorly uploaded from their original sources is now also effectively impossible. If you're going to limit the users, it should be limited to something rather wide like autoconfirmed rather than something like autopatrolled who's complete sum of users numbers only a little over 1000. Ergzay (talk) 01:38, 5 November 2023 (UTC)

There are 7000 users with autopatrol rights and there are more than 800 users who can place the template to allow overwriting. GPSLeo (talk) 07:14, 5 November 2023 (UTC)

I guess my count was off, but it's still a tiny number of users. Should be autoconfirmed user list. Ergzay (talk) 04:36, 6 November 2023 (UTC)

"Many images" is probably less 0.01% of Commons nearly 100 M files. Then if you need to update some files, then request Autopatrol right. It will be accorded to any user in good standing. Yann (talk) 10:57, 5 November 2023 (UTC)

There's a reason that Wikipedia has entire guides on how to help users to figure out how replace images. It wasn't supposed to be wrecked with a policy like this. Ergzay (talk) 04:38, 6 November 2023 (UTC)

@Ergzay: I just got bitten by this new policy change while trying to update an unmarked map and turning File:Android KitKat.svg into a true vectorization. I didn't even know it was happening, definitely annoying. SergioFLS (talk) 17:38, 9 November 2023 (UTC)

My personal suspicion is this policy change was pushed by the subset of users who are very much of the opinion that most editors are a source of problems rather than as something to be cultivated. So in their opinion the best sort of wikipedia is a wikipedia where only the select few can edit it. This may just be my biases speaking though. Ergzay (talk) 19:37, 9 November 2023 (UTC)

Looking at who participated, it seems to have drawn a decent number of the users that keep the project running. The Squirrel Conspiracy (talk) 01:54, 10 November 2023 (UTC)

@The Squirrel Conspiracy What do you mean "keep the project running"? The "project" is literally the entirety of the idea of having a wikimedia commons for storing images. Wikimedia commons is a glorified image storage server. Ergzay (talk) 02:38, 11 November 2023 (UTC)

By that, I mean people that are very active in the various noticeboards, DR, etc. and therefore have a pulse on what's going on behind the scenes. The Squirrel Conspiracy (talk) 06:42, 11 November 2023 (UTC)

It's not like there isn't ways users can edit the files. Wikipedia has essentially the same policies for articles having to do with contentious topics or where there's a lot of edit warring by only allowing auto-confirmed users to edit them, or in some cases administrators. The problem here is that the problematic edits are way rampant, hard to detect, and there aren't enough users to portal files for problematic edits in the first place. Let alone are they necessarily easy to spot or deal with in the first place. Especially when it comes to things like minor edits to maps or emblems where there's a lot of fake information being added to them that can only be verified through an obtuse amount of research and discussion. Not to say this is the "best" solution, but it seems to be the only viable one at this point. Otherwise we would be allowing Commons to be used for spreading false, nationalist propaganda just for the sake of not upsetting the few users who aren't willing to request the ability to edit files because "my freedoms" or whatever. --Adamant1 (talk) 02:00, 10 November 2023 (UTC)

@Adamant1 You say that problematic edits are "rampant" but the same is true of anything in Wikipedia. Problematic edits happen literally all the time and there's no easy way to detect that other than seeing that it has happened. We don't block all users from editing all wikipedia pages across all of wikipedia just because of that. Ergzay (talk) 02:20, 11 November 2023 (UTC)

This can certainly block many well-intentioned edits from casual users. Many times though, uploading a new version is preferred so that other users/projects can choose between the options (too often, files are overwritten just to avoid using User:CommonsDelinker to changed to a preferred new file; it's the path of least resistance to change an image on a Wikipedia page and it should not be). Overwriting is saying the previous version is worthless to use by anyone for any reason, since nobody can use it anymore. There are some unambiguous improvements though. Could the Allow Overwriting template be transcluded from templates like {{FakeSVG}} which are intended to point out problems that should be fixed by new uploads? I guess that could prevent regular users from adding such error templates, though (or if that was allowed, then someone could add one of those templates, then perform an upload, then remove the template to dodge the patrol need). SVGs in general are more intended to be edited (wasn't there an effort to have an inline editing tool at one point), so perhaps those could be allowed by default if they prove to be most of the reasonable reasons for editing we are now making more difficult. There are some merits to the arguments on each side, to me. Carl Lindberg (talk) 16:05, 23 November 2023 (UTC)

"Overwriting is saying the previous version is worthless to use by anyone for any reason, since nobody can use it anymore". I think that a message like this should be shown to the user when overwriting a file, to make him/her conscious about what it's being done. On the other hand, here we see that a file redirect can be used to keep a pseudo-file up to date, without need for overwriting. This is almost the same as versioned files that @Ergzay supported, so I think true file overwrites should be restricted to a minimum (specially on files not explicitly marked as updatable): no one should overwrite them, except if fixing errors, or if the original uploader wants to make improvements on an own work shortly afterwards. Files marked as updatable should be allowed to be overwritten by every registered user with some edits, since they work in a Wikipedia-like mode. Every file that isn't updatable, whose current state could be useful in the future, should ever remain as is, using a redirect if an updated version is needed on multiple Wikipedia (or other wiki) pages. We should think about Commons as about a library or a museum: it hosts content that must be preserved for future generations (some of the content may not be available at any other place, or it may become unavailable at other places in the future, so we have to take care about it). MGeog2022 (talk) 14:49, 27 November 2023 (UTC)

To answer @GPSLeo's comment, you deal with problematic edits just like how everything on Wikipedia works. When you see them you fix them. Articles across all of wikipedia are full of correct-looking information that's slipped in without being noticed. There is nothing unique about images here. Ergzay (talk) 02:38, 11 November 2023 (UTC)

And to answer @Ymblanter's comment, uploading new images is not sufficient. It breaks the chain of edits on commonly updated images. It's exactly like wanting users to create a new copy of a wikipedia page every time they want to update it and archiving the old page. The solution here is not to block all users from editing, but to catch users editing things improperly, contact them on their talk pages and if they refuse to comply, taking administrative action, just like how everything is handled on Wikipedia. You don't get to just block everyone out. Ergzay (talk) 02:39, 11 November 2023 (UTC)

I see your point but your approach to the issue is not really AGF. Antithesis of how wikipedia operates? You can just make a request to have autopatrolled rights and explain why you need it. Paradise Chronicle (talk) 06:43, 11 November 2023 (UTC)

@Paradise Chronicle I'm not arguing on my behalf I'm arguing on behalf of the numerous users this will affect. Namely I care that this will affect the quality of Wikipedia as a whole as more and more "bad images" accumulate with them being unable to to be fixed. You have to remember that doing all that stuff you mentioned requires effort and most people have little effort. They see small errors and they submit small fixes. Now all of those people are going to be cut out from being able to fix things on Wikipedia. Ergzay (talk) 16:51, 11 November 2023 (UTC)

As a Wikipedia editor, I hate images changing behind my back. You replace an image, that shows up in my watchlist. You tweak the colors on an image, a dozen Wikipedias may need to change their captions explaining the colors, but none of them get the notice. And if one of them wants the original colors, and reverts it back, again, no notification on the watchlist.--Prosfilaes (talk) 02:12, 12 November 2023 (UTC)

That's a software deficiency that could be fixed. Ergzay (talk) 03:18, 17 November 2023 (UTC)

You seem to be familiar with the policy, so I have just given you an autopatrolled flag. Please do not remember not to overwrite images taken by other users. Ymblanter (talk) 07:32, 11 November 2023 (UTC)

I replied similarly to Paradise Chronicle, but this isn't about me. This is about the quality of Wikipedia as a whole that this will affect. I care about all the users who see mistakes but just decide its not worth the effort to jump through hoops to fix the errors and just go on their way. This gradually wears down and destroys the quality of Wikipedia. Ergzay (talk) 16:52, 11 November 2023 (UTC)

We used to have way more bad overwrites than good ones. This is why the flag is need to overwrite the uploads. Ymblanter (talk) 16:54, 11 November 2023 (UTC)

I've personally never seen a bad overwrite on an image that didn't get relatively quickly reverted. Aren't you just seeing selection bias and only seeing the tiny fraction of images that had problematic edits (which is still a huge number of images because it's a tiny fraction of a gigantic number)? Ergzay (talk) 16:57, 11 November 2023 (UTC)

I am sorry to say this but as an administrator I have probably seen way more things that you have seen or ever see here. Anyway, since you have not really presented any new arguments, I will stop replying to you. Ymblanter (talk) 17:00, 11 November 2023 (UTC)

Of course, that's why I was saying you have selection bias. An administrator will see all the problems more than they'll see the norm that isn't issues. It's unfortunate you wish to no longer discuss this however. Ergzay (talk) 17:05, 11 November 2023 (UTC)

Actually a good point here is that we should facilitate the autopatrol for the users who really need it - such as updating maps etc. Do we have a link in the notice which advises the users to request autopatrol? --Ymblanter (talk) 07:34, 11 November 2023 (UTC)

Giving everyone autopatrol rights isn't really a solution here. There's too many casual editors that fix mistakes that now are unable to do so. Ergzay (talk) 16:57, 11 November 2023 (UTC)

Yes, it is the solution. Actually it is a general solution. If all good users are autopatrolled, then it is much easier to patrol potential vandalism or unwanted edits. Yann (talk) 16:24, 23 November 2023 (UTC)

This has been one of the most stupid changes done to this site, now instead of just updating a file, people will just upload a new file and replace the link in all wikipedia pages, what a waste of time.--Yilku1 (talk) 21:34, 29 November 2023 (UTC)

@Yilku1: This is what Commons policy says you should do. So you better read Commons policies instead of complaining here. Yann (talk) 22:02, 29 November 2023 (UTC)

@Yann: Why do you tell me to read the policies if i can't upload a new version? Those policies are useless to me. Those policies are just for the privileged few that can upload a new version. Yilku1 (talk) 18:50, 30 November 2023 (UTC)

Yes, that is almost always the preferred approach, so other users then have a choice and can pick the version which better suits their needs. They can go back to the first one with a simple Wikipedia edit, rather than version-warring on Commons, and looking back at page history would show the image which was actually used then. There are some legitimate reasons to replace a file though, and it would be nice if we could mitigate the problems there. Carl Lindberg (talk) 01:54, 30 November 2023 (UTC)

@Clindberg: There are going to be thousands of duplicated images and a lot of waste of time thanks to this stupid change. Yilku1 (talk) 18:51, 30 November 2023 (UTC)

@Yilku1: Please stop insulting those of us who !voted for it.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 19:21, 30 November 2023 (UTC)

@Yilku1: There will be thousands more options for projects to use, which is the entire goal of Commons, and not removed from being able to be referenced. It's regrettable it takes more time to do it the better way, but that was the entire point of the change -- people were taking the overwrite shortcut instead. It was easier to do the wrong thing, than the right thing. If they are not truly duplicate images, then overwriting is often wrong. The problem with the change is more for files and situations where overwriting was the correct thing to do (such as a higher resolution version). When it's something like a different preferred crop, that's not a duplicate. SVGs admittedly are often made for editing, more than bitmaps, so there are likely more situations there. Carl Lindberg (talk) 22:35, 30 November 2023 (UTC)

@Yilku1, @Clindberg, the second point here is something to be taken into account. If multiple Wikipedia pages use an image whose content is to be kept updated, creating a file redirect (and keeping it updated) would allow to use the updated image in all of them, while at the same time allowing to use past versions when desired (overwriting the image wouldn't allow that last thing). MGeog2022 (talk) 13:57, 1 December 2023 (UTC)

Yep, that's a very good solution too. For some images, like maps which change over time, that would allow for older historical versions to still be available. Carl Lindberg (talk) 22:44, 1 December 2023 (UTC)

I strongly agree. This policy change is incredibly harmful to the Wikipedia project, and goes against the spirit of collective improvement and collaboration. Making it so that only editors with 500+ edits on Commons can make improvements to image files effectively turns files into frozen assets for which anyone wanting to make an improvement must create a new minor name variant and then modify every encyclopedia page using the image to point at the updated version. This encourages a proliferation of competing variants whose defects can never be fixed in place. Jacobolus (talk) 22:16, 2 December 2023 (UTC)

What alternative do you suggest to force the people to read and follow the guideline? GPSLeo (talk) 23:34, 2 December 2023 (UTC)

In the past 2 decades, this hasn't really been that significant a problem. There are occasional edit wars about images (like any other content in Wikipedia), and vandalism is a persistent (manageable) problem, but there are also very frequent improvements to images which would have been prevented by this technical restriction. You're throwing the baby out with the bathwater here, and further turning Wikimedia into an exclusive bureaucracy vs. an inclusive collaboration. Jacobolus (talk) 23:42, 2 December 2023 (UTC)

@Jacobolus, I'm not a Commons administrator nor patroller, but taking a look, I've seen, for example, photos replaced by very different photos about the same subject, only because the new photo fitted into the title. Certainly there are many content in Commons that is not critical to remain "as is" forever, but many other content, it is. I think the problem here is about the multi-purpose function that Commons has. For some things, it's like Wikipedia (as with much, but not all, of user-created content), and for other, it's more like Wikisource (most third-party works, that are to be preserved as they are; if there are multiple versions of it, each one of them is to be uploaded separately). Even for user-created content, versions of maps that reflected past situations, for example, are, or can be, of interest in articles about the history of the subject. So I totally agree with this policy change. The matter here is to correctly mark as updatabe the user-created maps or diagrams that are to be updated (I think no photos, third-party works of any kind, or even some user-made maps/diagrams fit here), and use file redirects when an updated version is needed across multiple wikis. I think they should be used more, since they allow some kind of "file versioning" that is very useful. MGeog2022 (talk) 13:46, 3 December 2023 (UTC)

In cases where someone makes a mistake, it is easily reverted (just as for textual content). This is not a critical problem. Jacobolus (talk) 18:08, 3 December 2023 (UTC)

@Jacobolus, it's a problem if nobody notices it. I'm not talking about vandalism or obvious mistakes, but about cases when there is a legitimate reason to want the content updated (for example, an updated map). Commons stores maps that are (or will become over time) historical documents. We don't want them becoming in fact almost inaccessible due to someone (with good intentions) overwriting them to use the most recent version. To use an example I know well, there's the map of Madrid in 1982, and in 2015. They're both used on a Wikipedia article, as maps of the city at different points in time. Let's suppose I had only uploaded the 1982 version, and forgot to include the year in the title. Let's suppose the map is only used in the "Madrid" Wikipedia article. Someone finds out that the map is 40 years old, and overwrites it with the 2015 version (the title makes no reference to any year, and it isn't used in any context as a historic map). Then, we have in fact lost a very useful map, and part of section about evolution of the Madrid map in this Wikipedia article wouldn't be possible today. That's the kind of situation that I say we have to prevent. MGeog2022 (talk) 20:19, 3 December 2023 (UTC)

(Of course updated maps are absolutely necessary, so we should use file redirects for them when needed) MGeog2022 (talk) 20:22, 3 December 2023 (UTC)

The previous image versions are not deleted, so if someone makes that mistake (compounding the original mistake of a specific image being given a poorly chosen too-generic title) you can revert it and move their replacement image to a new title. This kind of thing certainly happens, but it's not an insurmountable problem, and can be handled by local discussion and collaboration and sometimes a bit of elbow grease. Jacobolus (talk) 20:28, 3 December 2023 (UTC)

@Jacobolus, but I don't know how many people are usually looking at file history unless something obviously wrong is detected. I try to be understanding, but I think the decision that could cause the least harm has been made. I insist on make known the existence of file redirects to ease usage of updated files when needed. For user-created maps and diagrams, that could contain mistakes that are to be fixed by other users (that's not the case for third-party works, even if they contain mistakes: they should be fixed in a derivative work, if desired), they should be marked as updatable. If they are to always reflect updated data, it should also be clearly specified, so the file is never used in a context that presupposes data for a certain date. MGeog2022 (talk) 21:08, 3 December 2023 (UTC)

decision that could cause the least harm has been made – the folks here making this decision never even considered any of the harms involved, which are primarily down to blocking image improvements and discouraging contributions. You'll never see the results because the improvements that never get made and the potential collaborators chased away are invisible and counterfactual. Jacobolus (talk) 21:10, 3 December 2023 (UTC)

Why do you think insulting us is helpful? Yes, we've thought about it. We just disagree about the importance of it.--Prosfilaes (talk) 21:25, 3 December 2023 (UTC)

I'm not insulting anyone. I looked at the relevant discussions I could find (from 2012) and the trade-offs were never mentioned by supporters; there was significant well-argued pushback from a variety of people who opposed the policy change, but it was pushed through without really answering those concerns apparently based on a majority-rules criterion. I couldn't even figure out where the recent technical block enforcing this policy was discussed; that discussion is not linked anywhere. As far as I can tell there was also never any effort made to inform or discuss with affected contributors of other projects. Overall it seems like a small and insular group casually making a high-impact decision without much consideration of effects on everyone else. –jacobolus (t · wp · wt) 22:02, 3 December 2023 (UTC)

So if the people making the decision didn't make arguments you agreed with, they never even considered any of the harms involved, even if they were talking to people who mentioned the harms involved. That's insulting. We could describe the response as "a small and insular group" arguing "without much consideration of effects on everyone else"; you've never even acknowledged that other projects besides Wikipedia exist, that Commons has value in and of itself.--Prosfilaes (talk) 01:25, 4 December 2023 (UTC)

@Jacobolus: The RFC making this a guideline concluded 15:46, 3 October 2012 (UTC). Too many people didn't follow it, so the proposal to "Limit file overwriting to users with autopatrol rights" was accepted with many supports and one weak oppose 15:19, 23 September 2023 (UTC). After an implementation problem in phab:T345896 and testing, Special:AbuseFilter/290 went live with the Disallow action 09:35, 28 October 2023 (UTC).   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 22:56, 3 December 2023 (UTC)

Thanks for that. (That second link should be linked prominently from Commons:Overwriting existing files.) As you can see, this was a low-participation discussion which didn't really consider the trade-offs involved and didn't make any particular effort to reach out to affected stakeholders. My expectation is that the long-term effects will be substantially negative. But my impression is that other folks in the discussion here don't really seem to care. So I'm not sure what else to say. –jacobolus (t · wp · wt) 23:15, 3 December 2023 (UTC)

If you change a file, you need to check whether that changes the caption or other context of a file. You're advocating for making it easier for people to change images on pages in languages they can't read or effectively edit. And again, the whole world isn't Wikipedia.--Prosfilaes (talk) 11:16, 3 December 2023 (UTC)

Responsible contributors do make that check, and even go make the appropriate changes to other-language Wikipedia articles where necessary. For example I redrew the diagram File:Eccentricity.png at higher resolution with a better use of colors and more information included, and changed the labeled point from the label "M" to "P". Since this image was in use across ~25 Wikipedia languages, this required clicking through all of those articles and checking whether they referred to the letter M, and changing the article text to match where necessary.

But occasionally there's a mismatch between article text and image which takes a while to be rectified, or e.g. changing the resolution of the image causes it to render incorrectly for a while where someone used 'frame' instead of 'thumb', and that's also usually okay.

I'm advocating assuming competence and good faith, and then helping contributors to get there and gently correcting them when they mess up. The new policy instead assumes incompetence or malice, refuses to let newcomers learn via mistakes, and forces good contributors to jump through heaps of bureaucratic hoops. The long-term result of these philosophies is fewer competent contributors, and contributors at every skill level who feel less positive about the project and less motivated to contribute. Jacobolus (talk) 18:40, 3 December 2023 (UTC)

I don't think your argument is without merit -- on the surface, don't like precluding the "everyone can edit". On the other hand, I don't think we are preventing that -- you are still free to upload under a different filename, and change articles to point to that. Nothing is prohibiting editing, really, just the ability to remove other people's work from being used, which is what an overwrite does. In your example, it would have been equivalent effort to upload a new image, and change the 25 usages, if you were being careful about it (which you were). Or use User talk:CommonsDelinker/commands to get the links changed. And the old image would then show up when you look at historical versions of the article text, instead of the new image being mismatched with the old descriptions, so it's easier to see the improvements to the article over time. You say "better colors", but in many cases that can be subjective, and an overwrite means nobody can disagree -- all Wikipedias must choose one image or the other, rather than there being a choice. There are some improvements which are unambiguous for sure, but many times it's not entirely clear-cut. Uploading separate images, creating choice, is almost always the preferred approach. Overwriting images is a difficult thing to notice project-wide, and mistakes can be quite damaging and not noticed for quite a while (many people may have a watch on an article and can correct mistakes; usually only one person, if that, is watching the image itself). Much of the time, such editors don't learn through the mistakes, if the mistake is not caught quickly. And if it's been a while, it makes reverting very difficult, as at that point then maybe many of the usages have text which refer to the new image, and other articles refer to the old version. At its core, overwriting an image is a destructive action. I would prefer that new users avoid doing that, and learn through independent uploads. I might understand exempting SVG images from this policy, as those are inherently more editable and not usually what a new user is doing. Carl Lindberg (talk) 20:15, 3 December 2023 (UTC)

And the old image would then show up when you look at historical versions of the article text, instead of the new image being mismatched with the old descriptions, this is a longstanding serious technical bug. The software should have long ago been changed to show the then-current image when you look at a historical version of a Wikipedia article. in many cases that can be subjective – there are obviously trade-offs and subjective preferences involved in making anything, but in this particular case the previous version had labels which were illegibly small in every place the image was used, and RGB "G" (#00FF00) on white is an illegible text color which violates every accessibility guideline you can find; someone might have different preferences than the replacement colors, but they are better than the previous choice by unambiguous objective criteria. many people may have a watch on an article and can correct mistakes; usually only one person, if that, is watching the image itself this is another severe technical bug – people should have a much easier time "watching" all of the images associated with articles they are paying attention to. overwriting an image is a destructive action In precisely the same way as changing article text, changing templates, moving articles, and many other kinds of improvements. These are decisions that should be made locally by discussion and consensus, rather than enforced by restrictions in the software. Jacobolus (talk) 20:19, 3 December 2023 (UTC)

If those longstanding serious technical bugs are ever fixed, maybe this could be revisited -- but that is and has always been the behavior, and we need to deal with that reality. As I said, it's more easily reverted if caught quickly, not so much when not caught for years. But no, it's not quite the same -- we can only choose one or the other image; when reverting text you can make edits while reverting, to keep some improvements, and revert things which are felt to be regressions. Or, you could choose to re-insert the old text as well -- making both available. Also if someone wants the old version back on an article, they can't just revert the text on that project -- they have to go to another project they may not be familiar with, and revert there -- but then that reverts for *everyone*. In an image's case, if you want the old one back, telling them to go take an old version and upload under a new filename is not a great solution -- the original upload had that name; it should stay there if both should be available. I certainly have on a handful of occasions reverted people who incorrectly overwrote an upload of mine, asking them to upload under a different filename, as the uploaded file was definitely a good thing to have -- but that doesn't always happen, once they make the effort once. That's not the best way to learn, either. I would prefer the default way, and path of least resistance, be to upload an alternate file then have a discussion where it's being used as to which is best. As you say, it is much better done locally, not globally by overwriting a central image. The way to do that is to have two images available, and have the local projects choose which one. We are an image database, and core policy is to have as many options as we can. If it's a mostly-obvious improvement like yours was, you can use the {{Superseded}} tag on the old one. Carl Lindberg (talk) 21:00, 3 December 2023 (UTC)

we can only choose one or the other image – this is just the same with text used in more than one place, e.g. from templates. If it's decided that some of the uses of a template have one set of needs and different uses of the template have a different set of needs, then the template needs to be forked with one of the two renamed, so that the two can be used independently. But most of the time it's better for everyone (both readers and creators) to focus on collaboratively improving a single version rather than trying to maintain a barn full of no-longer-used inferior historical variants with slightly different names. (By the way, these unused images regularly end up deleted from Commons on the grounds that they aren't being used; this does just as much damage to anyone trying to view historical wiki pages.) We are an image database – no this is a fundamental misunderstanding of the purpose of Wikimedia. We are hosting living documents designed to serve readers, not a database of miscellaneous pixel data managed bureaucratically for its own sake. Jacobolus (talk) 21:08, 3 December 2023 (UTC)

@Jacobolus, "By the way, these unused images regularly end up deleted from Commons on the grounds that they aren't being used; this does just as much damage to anyone trying to view historical wiki pages.": an image being unused isn't a valid reason to delete it from Commons; please see Commons deletion policy. MGeog2022 (talk) 21:12, 3 December 2023 (UTC)

This has routinely happened in the past. Maybe Commons policy has changed? Jacobolus (talk) 21:54, 3 December 2023 (UTC)

Policy has always been the same. When it comes to the judgement call of whether a file is educationally useful, being in use on another project means it's automatically in scope, as the judgement has been made by others. So the usage is often pointed out, but is not a criteria for deletion. Carl Lindberg (talk) 23:38, 3 December 2023 (UTC)

Again, Wikimedia is not Wikipedia. Wikisource is a Wikimedia project that most decidedly is not hosting living documents. Wikimedia Commons in and of itself is valuable to users, as simply an archive of artworks and images of various real life places and objects.--Prosfilaes (talk) 21:17, 3 December 2023 (UTC)

Okay. In that case Commons should advertise itself as a host of photographs of places and objects, and tell creators of maps, charts, diagrams, and other kinds of images to go elsewhere. Jacobolus (talk) 21:55, 3 December 2023 (UTC)

Or perhaps Wikipedia should move itself to a project besides Wikimedia, where it's all about Wikipedia and Wikipedia alone.--Prosfilaes (talk) 01:25, 4 December 2023 (UTC)

Of course images on Wikimedia Commons exist to serve readers and not for its own sake. But it's not only about readers of Wikipedia articles: it's also about readers of Wikisource, Wikinews, Wikiversity, non-Wikimedia websites, or even direct users of Wikimedia Commons itself. Even if we think only about Wikipedia readers, most unused images on Commons could be used from Wikipedia in the future. MGeog2022 (talk) 21:17, 3 December 2023 (UTC)

@Jacobolus: Wikipedia/Wikivoyage/Wikibooks/Wiktionary hosts living documents. Wikisource hosts source, static documents. Wikinews somewhere in between. Wikimedia Commons serves them all; and yes we are exactly that database of resources -- see Commons:Project scope. Part of our charter is to let images be embedded elsewhere -- so when overwriting an image, you could be changing it on websites we don't even know about (that is part of what to all means in the project scope). You may not care about that, but some do. As such, an image being unused is not a reason for deletion, unlike Wikipedia. If it has an educational use, and it's correctly licensed and hosting it doesn't violate laws like privacy, we tend to keep it. You are more citing Wikipedia policy, not Wikimedia Commons. We need to support Wikimedia and their needs, but they are not the only ones, and in some places we have different policies as a result. Carl Lindberg (talk) 21:22, 3 December 2023 (UTC)

If this is really the consensus view on Commons as a project, and the mission is so fundamentally misaligned, then Wikipedia articles should keep images on Wikipedia and refer to them locally instead of encouraging people to post images on Commons instead. Jacobolus (talk) 21:52, 3 December 2023 (UTC)

If by "misaligned" you mean that no project other than Wikipedia matters, I think the WMF would disagree. That has been the project scope from day one (or at least since I've been here). There are certain images that are meant to be edited; sounds like a template can be added to those to avoid this prohibition on those. It may be this creates some friction where there shouldn't be; those examples should be shown, to see if there is a solution. But I don't see how this prevents anyone from editing articles; just changes the way to do it (more in line with our policies). Carl Lindberg (talk) 23:38, 3 December 2023 (UTC)

@Jacobolus: You have 239 uploads. Most of them probably use {{Information}}. Suppose someone were to change that template, would you really want 239 notifications?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 21:31, 3 December 2023 (UTC)

I don't understand precisely what you are getting at. Why would you imagine anyone setting up a system where someone gets 239 duplicate notifications? I thought we were talking about the current inconvenience of putting images onto watchlists. Jacobolus (talk) 21:57, 3 December 2023 (UTC)

@Ergzay and Jacobolus: An example of what happens daily, and should not happen: File:Haseki Huerrem Sultan Roxelane.jpg. Yann (talk) 12:58, 4 December 2023 (UTC)

You'd prefer if this filename was left with the 638 × 800 pixel image from 2008, and then the 596 × 738 pixel version from 2008, the 1,492 × 1,807 pixel version from 2013, the 6,398 × 8,026 pixel version from 2015, the slightly brightened 6,398 × 8,026 pixel version from 2015, and the 567 × 686 pixel version from 2016 should each have their own filename? Then several different language Wikipedias should each have its own separate edit war switching back and forth between versions, and ultimately most of the Wikipedias should be left with slightly different inferior images depending on when the most recent translator happened to look at English wikipedia? I personally think that sounds much, much worse.

Notice that in the current situation someone can at a glance get the whole history of this image, and pretty trivially figure out what happened and what the dispute was. If someone wanted to have a conversation about it between participants, it could happen at (or be linked from) File talk:Haseki Huerrem Sultan Roxelane.jpg. The alternative situation where we have 5–10 minor variant filenames for every painting in the world is going to make i much more difficult for anyone to figure out what happened, who was involved, what the dispute was about, and so on.

(P.S. the version you reverted to has poor white balance and is underexposed, and is obviously darker and yellower than the original painting, and it should really be fixed in Photoshop by someone who knows what they are doing and has some clue what this painting looks like in person.) –jacobolus (t · wp · wt) 14:57, 4 December 2023 (UTC)

@Jacobolus: I would prefer to see an even brighter version of the highest resolution 6,398 × 8,026 pixel version from 2015, uploaded with a separate filename with intrawiki links and with categories per the guideline.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 16:22, 4 December 2023 (UTC)

@Jeff G. In an ideal world every contributor would spend an extra hour fixing up each image, completely describing the details about the origin and history of both the painting itself and this photograph, linking to relevant Wikipedia pages and to other relevant websites, and so on. But in practice people are busy and are going to do the most convenient thing and give up if it gets too complicated. So I expect this policy would lead to either (a) 5–8 different versions under slightly different filenames (all of which are crummy in different ways, used inconsistently across different Wikipedia pages / languages, and probably not all cross-linked to each-other), or (b) the original 638 × 800 pixel version at this filename with other contributors trying to fix it, hitting an "insufficient privileges" error message, and then just leaving because figuring out the bureaucratic workaround isn't worth the trouble. –jacobolus (t · wp · wt) 17:50, 4 December 2023 (UTC)

In practice, I see no problem with different versions of paintings ending up in one category for that painting. We have a lot of people working on categorizing. I see no problem with different versions of the image getting used on different Wikipedias. While we're making up stories, what if the person who knows what the painting looks like is a Turkish art historian who knows Turkish, Ottoman Turkish, Arabic, and Persian, but no English, and letting him upload the best version of the painting, without fighting with English speakers? Insistence on having one image may drive him away from Wikimedia projects, whereas letting him upload his version and change it on Wikipedias he can read and discuss on may earn us a strong contributor. People who leaving just because they're asked to upload a file separately strike me as people who are going to refuse to worry about copyrights or consensus.--Prosfilaes (talk) 22:14, 4 December 2023 (UTC)

While we're making up stories, – well, is there anyone gathering data about this? Doing user studies? Checking if the new policy is having whatever desired effect without causing unintended negative side effects? Did anyone proposing/supporting this policy consider what ways it could be measured and evaluated? That we all need to turn to speculation here without anyone even attempting to check results in some kind of evidence-based fashion seems like a critical failure of the entire decisionmaking process. –jacobolus (t · wp · wt) 02:59, 5 December 2023 (UTC)

Turning this back on you, is there anyone gathering data about the problem of blindly accepting overwrites? Doing volunteer Patroller, Licence Reviewer, and Admin studies? Checking if blindly accepting overwrites is having whatever desired effect without causing unintended negative side effects? Did anyone opposing blindly accepting overwrites consider what ways it could be measured and evaluated? That we all need to turn to speculation here without anyone even attempting to check results in some kind of evidence-based fashion seems like a critical failure of the entire decisionmaking process.

We do have some evidence that the reduction of the quality of the files and their freedom we provide to our audience due to this problem are palpable - people have been complaining about it on our noticeboards and on sister projects for many years. It can even be measured in the size of the DR backlog since Jcb left and took his highly-efficient systems with him, as well as the quantity of transclusions of {{Dont overwrite}} and {{Dont overwrite/en}}. The fact that the proposal was started by overworked Admin GPSLeo (and supported by other overworked Admins, as well as overworked License Reviewers and Patrollers) is not lost on me.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 05:27, 5 December 2023 (UTC)

@Jeff G. Usually the group proposing massive changes is the group that should do the studies. The fact you're turning it back makes it clear that there weren't any though. Ergzay (talk) 10:21, 6 December 2023 (UTC)

This is just a bureaucratic gambit; aren't you one of the people arguing against more bureaucracy? Solid testing is good, but it's usually too expensive for many purposes. The gambit comes in when you take one untested solution and then demand that any alternative undergo very expensive studies. To quote you, "Freezing everything in amber ... is complete antithesis to Wiki norms."--Prosfilaes (talk) 15:23, 6 December 2023 (UTC)

@Jeff G. I completely agree with @Jacobolus here. Perfection on wikipedia is impossible and there's always going to be some amount of error moving around. It's the job of editors to find and correct those errors. Freezing everything in amber because editors don't want to do their job is complete antithesis to Wiki norms. That's not the purpose of a Wiki. Ergzay (talk) 00:16, 5 December 2023 (UTC)

@Ergzay: The study is, among others, my 19 years experience on Commons, as a user and admin, with over 500,000 edits, and 286,688 deletions. Seeing that you uploaded 3 files, and have a total of 82 edits, you should listen a bit to people who are here longer than you. Hopefully that's sufficient. Yann (talk) 13:37, 6 December 2023 (UTC)

To others: Sorry if I am bragging but I am quite tired of brand new users who tell experienced ones how we should manage the project. Yann (talk) 13:51, 6 December 2023 (UTC)

More examples

Because of the new policy there were some requests to add more examples to these pages. Maybe we can collect some examples for what to overwrite and what not here on the discussion page.

Examples for what not to overwrite

• 
  Uploading a version without the background

Examples for what to overwrite

For these one we might need to create some duplicates to have good examples. GPSLeo (talk) 08:02, 4 November 2023 (UTC)

• 
  Overwritten by the uploader for removing unnecessary frame directly after uploading. Other users should ask the uploader and if the file was uploaded a while ago it should not be overwritten like this.

What about {{Opaque}}? SergioFLS (talk) 17:51, 9 November 2023 (UTC)

Updating maps

The policy says that "Changes that reflect different data (e.g. updating a map), where the file has not been marked as updateable" are not allowed, which is in complete violation of standard practice on Wikipedia. Maps are designed to be updated and in fact should automatically be flagged as updatable. This is particularly true of political maps or product release maps. There's entire guides on wikipedia in many locations on how to update and re-color maps as they need to be regularly updated. Whoever wrote this policy was completely out of touch with how Wikipedia works. For one data point, I've updated and replaced vastly more images than I have uploaded new, and that will be the case for most users. Just like there's very few people who create brand new pages on Wikipedia, most users simply update already existing pages. Ergzay (talk) 19:24, 9 November 2023 (UTC)

if updates are to correct errors, yes they should overwrite the erroneous versions.

but if they reflect real world changes like border change, name change, etc., they should probably be uploaded as new files. old files should stay as records of the points in history they represent.

as such, most maps should not be updated. RZuo (talk) 20:42, 9 November 2023 (UTC)

> if updates are to correct errors, yes they should overwrite the erroneous versions.

But currently that is impossible because of the Wikipedia-wide block on editing of images.

> but if they reflect real world changes like border change, name change, etc., they should probably be uploaded as new files. old files should stay as records of the points in history they represent.

I'm primarily talking about maps that are colored. Also old images that are not linked to any page on wikipedia can and probably should be deleted, not kept around for no reason. Also see maps like [1] that need to be constantly updated. Ergzay (talk) 02:27, 11 November 2023 (UTC)

If you want to store images on Wikipedia, you can do that. But Commons is not a store of images that Wikipedia is using; it's a collection of images that can be used by quite a number of different Wikimedia and non-Wikimedia projects. I understand that anybody can set up a Wiki and have it use Commons images directly from Commons.

Why should that image be constantly updated? Should File:Situation on Bataan 8 Jan 1942.jpg be updated to the current day? Why not give Wikipedias and Wikinewses the ability to specifically reference a particular day or a particular update, rather than imagine the only thing useful to them is the up-to-date situation.--Prosfilaes (talk) 02:23, 12 November 2023 (UTC)

@Prosfilaes I'm personally a big fan of versioned images. You should be able to link to a specific image version. Ergzay (talk) 03:20, 17 November 2023 (UTC)

If things were different, then we'd be making different decisions. But there's no ability to link to a specific image version.--Prosfilaes (talk) 04:47, 17 November 2023 (UTC)

I would additionally like to strongly suggest that Special:AbuseFilter/292 be updated to allow the creators of pages to add the "Allow Overwriting" tag. The addition of filters 290 and 292 is completely upending standard practices for updating election maps on Wikipedia. Updating maps with new information such as retirements is a community effort. It is also rather likely that the original uploaders of many current election maps are unaware of these new changes, so they will not know that they are now the only ones allowed to update the maps they uploaded. As a common practice, I believe that uploaders should be able to designate their own files as overwritable, avoiding the need to submit cumbersome requests to a small subset of users with the rights to do so. I also believe that there should be a general exception to filter 290 to allow for the overwriting of election maps, restoring our ability to exercise our standard practices. OutlawRun (talk) 16:06, 11 November 2023 (UTC)

That is a good suggestion. I changed the filter that the original uploader is now also allowed to add the template. I think this is primarily a problem of the first months. In the future nearly ever page with the {{Current}} template will also have the {{Allow Overwriting}} template. GPSLeo (talk) 16:50, 11 November 2023 (UTC)

I personally do not see that images should be allowed to be updated, getting the {{Allow Overwriting}} tag, as very few will know of its existence. Ergzay (talk) 17:01, 11 November 2023 (UTC)

That is the reason why we need them to make individual requests. If they would read and follow the guideline we would not need the filter at all. GPSLeo (talk) 17:05, 11 November 2023 (UTC)

I don't follow what you're saying. Ergzay (talk) 17:06, 11 November 2023 (UTC)

You wrote that the people do not know how to request the permission. And I replied that this is the reason why we have this filter. If the users would read the guideline they would know how to request permission. But if everyone would read the guideline and also follow the guideline we would not have the problem of bad overwrites anyway. GPSLeo (talk) 17:11, 11 November 2023 (UTC)

@GPSLeo Can we treat the {{Current}} template as if it is the {{Allow Overwriting}} template in Special:AbuseFilter/290, effectively allowing all images depicting current situations to be overwritten as the status quo ante?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 04:45, 12 November 2023 (UTC)

This would be possible but then the limitation for placing {{Allow Overwriting}} would be useless as {{Current}} can be placed by everyone. I would suggest that we let a bot place {{Allow Overwriting}} on all page with {{Current}}. GPSLeo (talk) 07:40, 12 November 2023 (UTC)

@GPSLeo: FYI, this tool places the number of transclusions at "104471". JeffGBot could do this with AWB if it had my rights. I don't have a machine powerful enough to do this with VFC. What other bots have autopatrol?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 11:24, 12 November 2023 (UTC)

I think you mean patrol, all bots have autopatrol rights. I would just add an exception for bots. I think every bot operator is trustworthy to add the template. GPSLeo (talk) 11:31, 12 November 2023 (UTC)

@GPSLeo: Now running, this could take 3+ days. I have noticed that most of the files are images based on Australian Bureau of Statistics data that were uploaded by 99of9.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 12:08, 12 November 2023 (UTC)

Thanks, I support allowing overwriting for that batch of ABS graphs. --99of9 (talk) 03:37, 14 November 2023 (UTC)

In the early morning of 15 November UTC at about 03:44, my laptop decided to reboot while I was asleep. The job is recovering, and should be making new edits soon. I have learned from this that I should save the progress of long jobs frequently, because AWB won't unless I use Option "Auto save settings file every 10 pages". Sorry for the delay, but the size of Special:PrefixIndex/File:ABS-6291.0.55.003-LabourFor is not helping.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 08:58, 15 November 2023 (UTC)

The job began producing results again 19:03, 15 November 2023 (UTC). It might be done around midnight UTC.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 20:09, 15 November 2023 (UTC)

I left my laptop alone for a few hours and it rebooted again, leaving a hole from 00:40, 17 November 2023 (UTC) to 02:49, 17 November 2023 (UTC). "Auto save settings file every 10 pages" did the trick, the job only had to skip 9 files this time.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:11, 17 November 2023 (UTC)

@GPSLeo It finally finished at 08:08, 17 November 2023 (UTC). Sorry for the delays.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 11:15, 17 November 2023 (UTC)

the tracking cat just became useless. with 100k files permanently placed in it it's as good as nothing. RZuo (talk) 15:18, 12 November 2023 (UTC)

@RZuo: Sorry about that, it couldn't be helped.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 15:21, 12 November 2023 (UTC)

@Jeff G. Good god what kind of junk is this? Completely breaking wikipedia content and you say "sorry it couldn't be helped". Don't you realize the obviousness of this policy doing drastically more harm than good? Ergzay (talk) 21:25, 16 November 2023 (UTC)

@Ergzay: What about the harm that malicious overwrites in the face of overworked patrollers and Admins were doing to our (and consequently Wikipedia's) content?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:06, 17 November 2023 (UTC)

@Jeff G. They'll get fixed over time just like everything else gets fixed on Wikipedia, by editors who happen to see the errors and revert them. Ergzay (talk) 03:10, 17 November 2023 (UTC)

why are maps like File:1962 North Indian Ocean cyclone season summary.jpg "current" and allowed to be overwritten? what new development will there be in 1962?--RZuo (talk) 09:04, 15 November 2023 (UTC)

@RZuo: {{Current}} is transcluded by {{Hurricane season auto track map}}, which was transcluded by this file 16:56, 24 April 2013 (UTC). Conceivably, there could be more information from cyclone hunters' trips in 1962 that hasn't been digitized or incorporated yet.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 10:36, 15 November 2023 (UTC)

now i just spent some time looking at the templates and cats. those with {{Recent}} and {{Update}} are suitable for overwriting, but those with {{Current}} mostly dont actually need overwriting. RZuo (talk) 11:16, 15 November 2023 (UTC)

@RZuo: Are the recent and update ones also current?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 11:20, 15 November 2023 (UTC)

I have undone some edits to the guideline by Ergzay. I think they reflected only his/her opinion, but as I can see here, there's no consensus to allow updating files when it isn't explicitly said. I'll add that, unlike Ergzay, I don't see any problem with the existing policy. If a file should be updated, it can be marked as such, so I see no problem in not allowing overwriting the vast majority of files (including maps) that don't need it. MGeog2022 (talk) 20:25, 16 November 2023 (UTC)

@MGeog2022: I warned the user for that.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 20:52, 16 November 2023 (UTC)

To clarify here because Jeff G is spreading misinformation here. I made the edit by standard Wikipedia policy of bold edits. I even mentioned that in the edit description. Consensus need not be established before making an edit. The edit was made before discussion even properly began. Look at the time stamps. Ergzay (talk) 21:19, 16 November 2023 (UTC)

@MGeog2022 @Jeff G. Pinging both users for awareness. Ergzay (talk) 21:23, 16 November 2023 (UTC)

"Consensus need not be established before making an edit" is totally wrong. We require consensus or at least a request is there are objections before any non technical change to any policy. GPSLeo (talk) 23:32, 16 November 2023 (UTC)

@GPSLeo WP:BRD "The BOLD, revert, discuss cycle (BRD) is one of many optional strategies that editors may use to seek consensus." Ergzay (talk) 03:13, 17 November 2023 (UTC)

@GPSLeo, @Ergzay, @Jeff G. "Consensus need not be established before making an edit" I think it depends on what kind of edit. When editing a Wikipedia article to add information, fix errors, etc, there is no need of previous consensus. The same for an image description page in Commons. But when there is a dispute, and, specially, when editing a policy, consensus is needed. For policies, I think that "The BOLD, revert, discuss cycle (BRD) is one of many optional strategies that editors may use to seek consensus." doesn't apply in the same way that for normal articles (if not, policies would be a chaos, if everyone that has an idea, modifies the policies according to it).

Returning to the root issue, I understand that certain Wikipedia articles need updated maps. But also, any map, and specially, any non-user created map, has an historic value in itself. For example, a 2000 CIA World Factbook world map, is a map of the world, a map of the world as it was in 2000, and the world map included in 2000 CIA World Factbook, all at the same time. As a map of the world, it's obviously obsolete. As a map of the world in 2000, it's useful, but other, even better, maps of the world in 2000 do exist and can be used. But as the world map included in 2000 CIA World Factbook, it can't be replaced, and it has a historic value in itself. I don't know if it would be possible to use some kind of file groping, for example, we have "mapname_2020.jpg" and "mapname_2021.jpg", and if in an article you need 2020 version, you use it, but if you need the most current one, you can do something like "mapname_most_recent.jpg". I don't know if something like this would be technically feasible, but probably we all would be happy with it. MGeog2022 (talk) 14:10, 17 November 2023 (UTC)

@Ergzay: This is not Wikipedia.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:03, 17 November 2023 (UTC)

@Jeff G. Wikimedia and wikipedia are the same thing. Ergzay (talk) 03:11, 17 November 2023 (UTC)

@Ergzay: Bzzt, wrong answer.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:13, 17 November 2023 (UTC)

@Jeff G. "Wikimedia Commons is part of the non-profit, multilingual, free-content Wikimedia family." Ergzay (talk) 03:16, 17 November 2023 (UTC)

@Ergzay: So is English Wikipedia. But they are not "the same thing".   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:25, 17 November 2023 (UTC)

They're governed by the same body and have the same policies. Ergzay (talk) 03:26, 17 November 2023 (UTC)

@Ergzay: No, they aren't governed by the same body (enwiki has an ArbCom, we don't), and they don't have the same policies. Enwiki gives three strikes for advertising, we only give one. Enwiki only respects US copyright law, we respect all copyright laws (within reason). Enwiki accepts fair use (subject to strict restrictions at en:WP:F), we don't (per COM:FAIR).   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 03:30, 17 November 2023 (UTC)

Minor differences in policy then. Ergzay (talk) 03:32, 17 November 2023 (UTC)

Not minor. The only policies they are shared are the WMF terms of use and the universal code of conduct. All what is not defined in these fundamental policies might vary in every Wiki. GPSLeo (talk) 07:58, 17 November 2023 (UTC)

No, Wikisource and Wikimedia are the same thing. Therefore there should be absolutely zero images updated to be kept current; all images should reflect the document they were scanned from and be unchanged except for improvements in scanning.--Prosfilaes (talk) 03:57, 17 November 2023 (UTC)

@Prosfilaes: I'm sure you meant to write that they "are not the same thing".   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 11:04, 17 November 2023 (UTC)

I meant to write what I wrote, but I was being facetious.--Prosfilaes (talk) 18:40, 17 November 2023 (UTC)

Replace my uploaded image

I read the page on what can and cannot be overwritten... but now, in practice, how do I overwrite my file? A few days ago I selected the wrong file to upload (the one without a shadow, which is not visible on a white background) and I only noticed it now. Sorry for my inexperience! --Wiccio (talk) 07:24, 29 November 2023 (UTC)

@Wiccio: Hi, and welcome. You may use the "Upload a new version of this file" link at the bottom of the "File history" section of any file you originally uploaded. How did you determine that {{PD-textlogo}} was appropriate for File:Avatar-la-leggenda-di-aang-logo-ita.png and other uploads?   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:07, 29 November 2023 (UTC)

@Jeff G. Most people update other people's images so this isn't the most useful statement for this person. If someone has uploaded their own image they'll know how to replace their own image. Again, wiki* is about editing/replacing. Ergzay (talk) 00:19, 5 December 2023 (UTC)

@User:Ergzay How is answering someone's question not the most useful statement? Even on the English Wikipedia, there's a lot of restrictions about who can edit and how; you can't just replace an article with what you want, and rewriting a whole article is likely to get you reverted. On the German Wikipedia, nothing can be seen until an authorized user approves it; see w:de:Hilfe:Gesichtete_Versionen. There's quite a variety of Wikis and quite a few different styles.--Prosfilaes (talk) 15:50, 5 December 2023 (UTC)

Definition of "digital restoration"?

Does the guideline that "digital restoration" be uploaded as a separate file apply to digital edits made to digital files, or only to the process of digitally restoring something ("a historical document or artwork") that was once a physical photograph or piece of art?

File:Yevgeny Prigozhin (13-06-2023).jpg, a still from a YouTube video, was edited by User:Kashmiri to make the image sharper and more detailed, increasing the resolution and adding aspects (either by hand based on other reference images, or by asking an AI to make its best guess) which were previously absent from the image, such as turning an ambiguous dent or mark on Prigozhin's cheek into a flat yin-yang-shaped symbol. When notified on their talk page they felt that such alterations were "perfectly within policy" because they see the COM:OVERWRITE exception as only applying to restoring physical photographs.

To my mind a digital YouTube still of a person is also a "historical document". Belbury (talk) 09:11, 19 December 2023 (UTC)

Hi, Better to upload as a separate file here. Yann (talk) 09:51, 19 December 2023 (UTC)

Is that a verdict on this image alone? The file had already been reverted under COM:OVERWRITE on the grounds that I'd contested it. I'm looking for some guidance for how to interpret the guideline more widely, and whether similar uploads from this user and others are appropriate.

Kashmiri's view on their talk page seems to be that if you start from a digital copy of an image, any digital edits you make to that aren't considered digital restoration, because digital restoration is something that only happens to analogue media. (From their other recent uploads like File:PostcardAHappyNewYear1912.jpg and File:Bundesarchiv Bild 183-27237-0001, Reinhard Gehlen.jpg it seems like they might be extending that reasoning to digital images which somebody else has scanned, that so long as your editing process doesn't start with you physically handling a real photograph, you aren't digitally restoring it.)

In the same comment they also seem to suggest that asking an AI to add details to an image doesn't fall under artificially upscaling or enlarging using any tool, including AI-based or deep learning services if the new file is the same pixel size. (I have seen that take elsewhere recently, of a user not considering it "upscaling" when they ask an AI to clean up a photo without increasing the resolution, even when the AI gives back a photo of a statue with a nose job and a faint fleshtone.)

Are either of these takes correct? Belbury (talk) 09:21, 10 January 2024 (UTC)

Disruptive policy

I find this new policy highly disruptive and in fact insulting. Nobody can update charts (e.g. File:Standard Model of Elementary Particles.svg) after they have done so for many years. It is absolutely usual for any editor to upload a new, improved version of a file. Blocking people from doing so because they are not the original uploader, is disruptive and offensive to the respective contributor. Nobody will want to work on improvements any more. The above mentioned file has been a replacement of a prior file since 2013, and many editors have provided updates over the years. I am the originator of the current version, yet I cannot update the file, nor can any other, while the prior originator is no longer active on Wikimedia. Same goes for many other files. This policy is a middle finger to quite numerous contributors and should to be dropped. Cush (talk) 18:24, 21 December 2023 (UTC)

@Cush: Hi, and welcome. You have triggered Special:AbuseFilter/290 by trying to overwrite a file that you did not originally upload. Please: read MediaWiki:abusefilter-warning-file-overwriting, Commons:Village pump/Proposals/Archive/2023/08#Limit file overwriting to users with autopatrol rights, and COM:OW again; don't trigger that filter again; and request Autopatrol group membership at COM:RFR when you think you are ready (once you have made more than 500 useful non-botlike edits), having that should allow you to overwrite. I also tagged that file with {{Allow Overwriting}} for you and everyone else similarly situated. You may also request that any other particular file or category of files be overwritable at COM:OWR.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:18, 22 December 2023 (UTC)

I have been the copyright holder of the mentioned file for ten years now, after the prior design was first adjusted and then replaced. But that is not the issue. This policy goes against the collaborative nature of Wikimedia and against the good faith edits of contributors. I have read the articles you hint at, and I find them appalling. All kinds of scientific charts or other presentations of structured information have been originated, modified, and enhanced by a multitude of contributors over the past decades. This is how this encyclopedia was intended to work. Now they are all blocked and are referred to some obscure policies and groups that require people to live on Wikimedia and not just work for it once in a while. Contributors are forced to join groups where people only manage other people's contributions, just to ask whether they could update material so that their respective edit would not be marked as abuse. That is degrading. If Files are uploaded that violate quality or legal requirements, they can be reverted. That ought to be enough. Furthermore, I resent the implication that I make bot-like edits and that someone judges their usefulness. Cush (talk) 15:53, 22 December 2023 (UTC)

If there would have been other solutions like merge requests for new file versions we would not need the current method of blocking overwrites. But getting complex new MediaWiki features would take many years. The problem you describe also only exists for existing files where the uploaded forgot to mark the file with {{Current}} or something similar as a file that should be overwritten. GPSLeo (talk) 16:43, 22 December 2023 (UTC)

Which contributor knows what {{Current}} even means or that it exists? I have seen it for the first time today, and I have been here over eighteen years. And how are the (many and severe) technical and organizational shortcomings of MediaWiki a just justification for killing collaboration? Editors should focus on the quality of their contributions and not on all the petty politicking about rules that has been going on on this platform for too many years now. With this policy, contributors are expected to debase themselves and beg and wait for some random group's approval, even for files that have had many edits over the years by many editors, and where the original uploader has perhaps long abandoned the subject. Usually, I can alter or fix and then upload files within minutes. If I have to wait for hours or days to perform an upload because someone demands to supervise, I will no longer upload. As I stated before, this is a middle finger to us contributors. Cush (talk) 18:38, 22 December 2023 (UTC)

Perhaps "Current" template needs more publicity, if some people continue complaining about this. Now that many things in Commons are to be redefined, this perhaps could be improved someway, but basically, the 2 Commons are to be differenciated: the Wikipedia-like files, that should include "Current", and the Wikisource-like, static files, that shouldn't. I also wonder why I can edit, even without logging in, works that are already complete in Wikisource, such as this. This goes beyond Commons, but the dual nature of Wikimedia projects should be more clearly defined: some things are to constantly evolve, while others are to remain forever as they are, and allowing edition of the last ones, only could make them worse. MGeog2022 (talk) 19:39, 22 December 2023 (UTC)

Well, first of all, "{{Current}}" is a bad name, as it does not implicate the template's purpose. Second, when a contributor uploads a new file, there should be a checkbox that will automatically place the template or any other collaboration option into the file properties, especially if the file has been released into public domain. And if some group insists on enforcing this policy even to ancient files, then the group members can be expected to go through all files and place the template themselves where applicable. The sheer amount of effort is then no valid excuse. Cush (talk) 09:38, 23 December 2023 (UTC)

@Cush, not all public domain files should be updatable (for example, ancient photos or documents), but I agree that a checkbox to mark a new file as "Current" (or other better name, if the template is renamed) would be a really good thing. Since a technical needs survey is being carried out, I'll suggest it there.

And if some group insists on enforcing this policy even to ancient files: the problem with ancient files is that many of them shouldn't be updated, so it's better to be cautious: when an updatable file is found, it's asked to mark it as "Current" to a user who can do it, and it's ready. That's better than risk overwriting many other files that should remain as they are. MGeog2022 (talk) 10:51, 23 December 2023 (UTC)

Request added (link). @Cush, you can comment on it if you want. MGeog2022 (talk) 11:07, 23 December 2023 (UTC)

I meant ancient as being a long time on Wikipedia, not depicting something old or of historical value. Maybe overall, files should be categorized by content. If it is of a documentary nature such as photos or scanned documents, the files should be treated differently from charts, tables, or other forms of presenting information that can become inaccurate or obsolete over time. Even so, even pictures of scanned documents or maps etc should be updatable by anyone if newer, better material becomes available. Binding a file to its original uploader is in any case not helpful, especially when considering that updates can occur decades later when the original uploader may not be around any more. Cush (talk) 11:21, 23 December 2023 (UTC)

I also meant that. Many files that have been here for much time, are historical documents (of course, many others not).

pictures of scanned documents or maps etc should be updatable by anyone if newer, better material becomes available: yes, if it really depicts the same document. The problem is when someone "updates" an old map, with a newer one, for example, or replaces "Bus from XYZ company.jpg" by a completely different photo of another bus from the same company, when a photo should remain the same (possible minor changes apart). And it seems that things such as this happened frequently. MGeog2022 (talk) 11:29, 23 December 2023 (UTC)

"I have been the copyright holder of the mentioned file for ten years now, after the prior design was first adjusted and then replaced. But that is not the issue."

that is exactly the issue.

Substantial changes or completely unrelated files

Major changes

Different files on the same topic

Changes to license

all these are not wanted for overwrites. respect for com:copyright is both morally and legally important. RZuo (talk) 10:32, 24 January 2024 (UTC)

Agree, this is the most stupid change done to the site. Why don't we just ban everybody from editing articles in Wikipedia because they could be vandals then? And only allow just a select priviliged caste to edit. Yilku1 (talk) 16:56, 20 January 2024 (UTC)

@Yilku1: Because we aren't. It's not "vandalism" really -- many well-meaning editors make the same mistakes. It's preventing what often seems like a logical action but which is actually a destructive action -- we are trying to prevent users from deleting other users' work, basically. You call it "edit", which sounds benign, but in reality it's deleting a previous contributor's work completely and replacing it with your own. Files are not articles -- for an article, you are trying to get the single best article for a given title. Commons is not trying to get the best image matching a particular file name -- we want as many choices for a topic as possible for others to choose from. Overwriting an image prevents that, and effectively deletes an existing file, and removes a choice. Another difference is that a Wikipedia article's copyright is assumed to be a group ownership of a single license -- but not files on Commons; they have many different copyright license which are owned by a single author. In many cases, "editing" can make a mess of copyright attribution -- there are copyright license aspects as well. The image that User:Cush was complaining about, he mentions that I have been the copyright holder of the mentioned file for ten years now. Right, but the file existed before that, and someone else owned that earlier copyright. Many derivative works were made of the original work, pointing back to that file as a source for the attribution -- but then he changed the author, and possibly the license, when fully replacing with a completely different image. Now the attribution on the previously existing derivative works looks like User:Cush was the original author, when they were not, and you have to dig through both earlier uploads and earlier file page edit history to discover the real author. If he had uploaded under a different filename, like the policy at the time said he should, then there would have been no problems -- he could continue to edit his image, and attributions elsewhere would not have been broken, and the previous user's work would have still been available as a choice rather than being removed from all projects permanently. To be sure, there are some situations where overwriting is a good thing (a higher resolution of the same exact photo). But the large majority of overwrites are done by users -- often experienced, well-meaning editors -- who are thinking along the lines that it's the same as an article, and not realizing the damage it can cause. Basically, if you are changing the author and/or license by uploading a new version, it should not be done on the same filename, but a different filename. Far too often, it's not. Carl Lindberg (talk) 17:36, 20 January 2024 (UTC)

If there is a problem just revert it, don't ban everyone from uploading. Yilku1 (talk) 17:50, 20 January 2024 (UTC)

We aren't banning anyone from uploading. We are trying to prevent overwriting. We want people to upload, just under a different filename. Not many people watch individual images other than their own, so the problem isn't usually noticed until it's far too late to fix with a reversion. And a revert then removes the second user's work, forcing them to upload again (and they may often not bother). That approach to overwrites has been shown to not work. Carl Lindberg (talk) 17:59, 20 January 2024 (UTC)

"We aren't banning anyone from uploading. We are trying to prevent overwriting". No need to be pedantic.

This changes basically ban 99% of people from correcting mistakes in images, and the only way is to be approved is if select priviliged caste deems you worthy enough to make the changes. This go against everything Wikipedia stands for. Yilku1 (talk) 02:03, 21 January 2024 (UTC)

Your assumption that we ban 99 % is totally wrong. 90 % of all edits here edits are done by users with this right. All active editors have this right. If you go to another Wiki or language version you will always have many restrictions until the local community finds you trustworthy enough. GPSLeo (talk) 08:04, 21 January 2024 (UTC)

"until the local community finds you trustworthy enough" That is not my experience. This seems new and particular to Commons. Who is the local community of Commons beyond admins who use this platform for holding influence over "ordinary" contributors by contriving policies and politics? Why would they themselves be trustworthy enough to make good decisions as a clique? Yilku1 is completely right that editors are discouraged from making updates to files (with changes propagating through all references). Suggesting to use a different filename is not helpful, as it would have no effect in all the national Wikipedias using the prior file or variants thereof. With these policies Commons is not protecting anybody's contribution, it is trying to own it. The once collaborative spirit of Wikipedia and Commons is gone. Cush (talk) 16:30, 23 January 2024 (UTC)

The local community of Commons would be the people who choose to work on Commons. Some of us have uploaded a number of files to Commons that might see use across Wikimedia without stressing about exactly where they might be used. Why would people who use Commons be familiar with problems that show up on Commons? It seems obvious.

"it would have no effect in all the national Wikipedias using the prior file or variants thereof" is exactly the point. Part of the point of this is preventing one user on Commons from changing every Wikipedia at once, no matter the local (and possibly touchy) consensus on, say, borders, or changing parts of the image that are mentioned in body text or caption, like colors.--Prosfilaes (talk) 01:29, 24 January 2024 (UTC)

So, when for a chart conveying a scientific subject new information becomes available, the policy wants only the original contributor to update all files in every variant and every Wikipedia. Same goes for visual/design improvements. Do I get that right?

Making charts and maps is somewhat more effort than just dumping photos into Commons, and the purpose is of course different. Commons is the storage for material used elsewhere, and because sooner or later material originating in other sites gets transferred here, contributors like me are forced to deal with all the bureaucracy and the obscure policies here. I occasionally contribute material but I do not live here. Cush (talk) 10:10, 24 January 2024 (UTC)

the policy wants users to overwrite only if they are making minor changes like updating info or correcting errors.

the policy seeks to prevent users from usurping other users' works and even removing attribution like https://commons.wikimedia.org/w/index.php?title=File:Standard_Model_of_Elementary_Particles.svg&diff=prev&oldid=796858164 .

since this user has violated this point of the policy and is now arguing about it, i think the new restriction is quite rightly introduced. RZuo (talk) 10:23, 24 January 2024 (UTC)

When new information becomes available, we want the upload to be a different file. The previous file was still valid at a particular time, and may still be useful in other situations, possibly even in other existing usages. Make a new file, which probably has a new or additional author anyways (and thus a different copyright owner), and switch links to that file. If you are the author of the original file, you have a lot more leeway. If there is a need to change the "author" field, it's almost always a mistake to overwrite. It is not -- at all -- similar to editing an article, and far too many treat files that way, thinking that changing them is in the same spirit of "anyone can edit" articles. The copyright and licensing do not work in the same way, and overwriting is often destructive. Fixing typos does not create a new copyright thus does not change an author or license, but many overwrites have problems in these areas. That is the crux of the problem -- most users do not intend to create problems with overwrites, and only intend to improve the article they are used in, but are unaware of other aspects (or want to ignore their complexity). You can't ignore the copyright complexity with overwrites -- you have to really understand all the issues, and that's the area most people want to ignore (understandably). So yes, if most files get pushed to Commons, the best way to avoid that complexity is to have a default for uploading changes as a separate file (while mentioning the source file). Most need to get out of the habit of overwriting a file just to change the image seen on Wikipedia; it's a constant source of problems. Carl Lindberg (talk) 14:27, 24 January 2024 (UTC)

I still fail to see the justification for punishing contributors. Look at a file like File:Ancient Orient.png, which is a map completely different from its prior version, but it still depicts the same thing. Why should people be blocked from updating or replacing such a informative depiction, of which there are countless other examples? Those who invent a new and spectacularly restrictive policy ought to be the ones who must also do the work to mark all Files accordingly, instead of enforcing an impractical requirement and expect others to just shut up and never enhance other people's work again, or otherwise beg some obscure group for approval because suspecting abuse is now the default position. This attitude is very uncollaborative if not insulting. Cush (talk) 12:19, 23 December 2023 (UTC)

Because that one should have been uploaded as a separate file, and the links on articles switched. It's a different depiction of the same thing, but not a duplicate image -- we want both available to be chosen. We aren't stopping anyone from improving pages, just from removing existing images when they do so. All we want is for people to upload under a different name -- you are overwriting someone else's work and saying it's worthless to be used again, by anyone on any project, when that happens. If you go back in page histories, you will always see your image, rather than the one which was there for many years before. People watching the article page don't get any notifications of the change, and there is no ability to change back if they disagree (not likely in that case, but not every case is that straightforward). Commons is about having more options. If images are used on other projects, such as say Wikisource which wants that exact image because it was part of a source document, it shouldn't be touched -- there are templates like those in Category:Dont overwrite-file templates because it happens all too often. People modify an image to improve one usage, but an overwrite changes all of them, on all projects, without anyone being notified really. Such an action does not let each project choose the one better for them, but makes the choice for all of them, and rarely do people check (or can read other languages to understand if a caption elsewhere is being invalidated). The COM:OVERWRITE guideline did not exist as it does now in 2010 when you made that change, but it has since 2012, and people still do not follow it. I'm sure another goal is to get more experienced editors the autopatrol right -- no reason for it to be obscure. In general though, I fail to see how it is all that much harder to upload the image under another name then switch the link -- that achieves the same result, and is the path the guideline wants people to take. Carl Lindberg (talk) 15:27, 23 December 2023 (UTC)

The File I originally referred is File:Standard Model of Elementary Particles.svg and has had 23 contributors in 15½ years, and the new policy now told 22 of them that neither are their past contributions appreciated, nor are new ones wanted. The File is used in numerous articles in many Wikis all over the world, albeit in various language-versions. In the English Wikipedia it is used in the infoboxes about all kinds of subjects relating to particle physics. What kind of "then switch the link" do you have in mind here? Cush (talk) 15:51, 23 December 2023 (UTC)

I do wonder if SVGs should be exempted from this change, as that is the most frequent valid use of updating existing images -- does seem to be blocking usage of tools like User:Rillke/SVGedit.js. SVGs are often incorrectly overwritten as well, but they are more meant to be editable in the first place. For the relatively rare cases where links everywhere should be switched though, you can make requests at User talk:CommonsDelinker/commands. That will at least get page and template watchers notified, and maybe particular uses can be reverted if inappropriate. Carl Lindberg (talk) 16:17, 23 December 2023 (UTC)

SVG files can not be excepted from this as edit wars on them are one of the main reasons for the policy change. GPSLeo (talk) 18:32, 23 December 2023 (UTC)

@GPSLeo: See also Commons:Requests for comment/Technical needs survey/Checkbox to mark new files as current on upload.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 01:51, 29 December 2023 (UTC)

the current version has different layout and design from the initial 2008 version. that's exactly a bad example for Commons:Overwriting existing files. who started the current design and overwrote the old version? RZuo (talk) 20:14, 23 December 2023 (UTC)

I believe that was User:Cush , in June 2013, who made the substantial design change. Much to late to revert now, but that would be against the (relatively new at the time) policy. I'm sure it was a better approach for the SVG, given that nobody reverted it, but that is exactly the type of thing we'd prefer in a separate upload. If User:Cush had uploaded it separately at the beginning, they would be free to continue to make updates/improvements to it as the original uploader. Carl Lindberg (talk) 18:18, 29 December 2023 (UTC)

@Cush: FYI.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 18:26, 29 December 2023 (UTC)

Feel free to revert the file to the design from before the overhaul. In mid 2020, there was a fuss over a super-urgent split proposal to separate the designs, but nothing came of it. I forget who the User was or where the request was posted. Cush (talk) 16:47, 23 January 2024 (UTC)

for future sake and everyone's benefit Commons:History merging and splitting/Requests/Archive 4#Split between years old revisions. RZuo (talk) 18:49, 23 January 2024 (UTC)

It was User:Speravir. Cush (talk)

Maybe I did not fully understand the matter of this thread, but you, Cush, could yourself still request a split pointing to my archived request and this thread we’re in. On the other hand I get the impression you still not have comprehended that in first place you shouldn’t have overwritten this file, but originally should have uploaded it separately. — Speravir – 00:34, 24 January 2024 (UTC)

I have no problem with anybody else going through all the bureaucracy of a request and then someone performing the split, but to be honest, the process is too convoluted for my laziness.

Maybe I should have started a new file, but a decade ago considerations were different. The focus was on the chart being as accurate as possible and visually pleasing. Ownership was not as important as it is today. Cush (talk) 10:27, 24 January 2024 (UTC)

If someone would like to do my work for me

I was in the middle of editing the page on Wikipedia for this cool plane. I ended up on the Commons page of an interesting but jpeggy and small image. I reverse-image-searched it. There's a higher-quality copy already on Commons under a different filename. File:North American Aviation plant, Inglewood, CA.jpg is in use on several pages. There is a much higher quality version of the photo at File:B-25 final assembly line at North American Aviation's Inglewood.jpg, which is also in use on several pages.

template:merge is only for merging pages. I don't think I can justify using category:duplicate because the higher-quality version has a slightly tighter crop than the terrible one, and the alternative actions suggested at that cat page are to request deletion and then if appropriate make the filename a redirect, or to have it renamed.

Having it renamed would remove it from articles on which it's in use on other projects and I don't know if a page here for a filename for which the file been deleted becomes "up for grabs", if a file: page can even exist without a file, and even if it can, I don't know if I still can't do anything because someone else was its originator and I'm not in the group of 7,000 or so users who comprise the "everyone" in the sentence "Wikimedia Commons uses the same wiki-technology as Wikipedia and everyone can edit it" who get to make edits to all the files on the file repository.

I am here because I want to be helpful. I am a normal user. Unless I go out with a camera or start trawling the rest of the web, this policy makes it so that the only helpful thing I can do specifically right here on Not Wikipedia, without enlisting the support of one of the aforementioned "everyone", is adding categories and metadata to files other people have uploaded. I want to stick the better file up as a new version of the old file, where the original uploader can revert the change if they're for some reason unhappy with it, and I want to make one of the pages redirect to the other. I want to fix the problem.

Commons:Overwriting existing files now tells me to request an exception for a specific file, or preferably, to "consult the creator or original uploader first as they are likely to do a better job of fixing issues".

On Flickr, I can upload my own file. I can replace my own file with new versions. I can tag another user's file. I can put that other people's file in galleries, which appear on the page for that file, in order to help others find more images on a similar theme. I can embed the image elsewhere on the web. But I CAN'T edit other people's files. If I want to do that, I have to submit a support ticket or message the user and ask if they'll do it for me.

This policy has turned Commons into an image-hosting site with unconventional content policies.

I post on Reddit. When I want to post an image, I drag it to my desktop, stick it on Imgur, and post the link to the site. There's every chance it's already been uploaded and posted in exactly the same manner, it's elsewhere on Reddit, it's elsewhere on Imgur, but I'm not going to go looking, because that's too much hassle.

I like to edit Wikipedia. By its nature, editing Wikipedia involves interacting with Commons, so I do have edits here and if I see something I can fix while I'm here, I sometimes try - but MOSTLY it's just editing Wikipedia. Maybe an eighth of time spent "editing Wikipedia" is doing things on Commons. It could be YEARS before I hit the "more than 500 useful non-botlike edits" threshold, especially since the editing I can do without getting help now amounts to categorisation gruntwork, and I don't think that, if pressed, supporters of this policy would qualify adding [[category:aeroplane]] to things as non-botlike. If something's wrong with an image on Commons and I want to fix it before I use it, there are so many situations where it is now so much less hassle for me to just upload a fixed version with a new filename and use that for whatever than it is to do it correctly. And doing that means I'm using this tool incorrectly, unless I endure a massive amount of faff. Am I going to go to the original file's page and click edit source and copy its list of categories over to my new version and replace the images in articles, perhaps on several languages of Wikipedias, with my new upload, and post a message to the original version's talk page to say I've uploaded a new version and consult the creator or original uploader to tell them they need to to do a better job of fixing issues than everyone???

...actually, it turns out that YES, I will do that, one time. Last week I was here, I found this, I liked it, I looked for a higher quality copy, I found one, I tried to upload it as a new version of the file, I ended up here. I read the discussion and was confused and frustrated. I reuploaded it under a new filename, I copied the cat tags across, I replaced the embed in that article, I posted a message to the OP's talk page, they replied, it worked. But IT WAS SO MUCH FAFF.

I do not want to submit a support ticket. I do not want to grind edits like I'm playing WOW to get autopatrol rights. I haven't even put anything in my user page here yet. I do not want autopatrol rights. I want to be able to be helpful. This change has made it massively more difficult to be helpful on this site, and to use this site to be helpful on the other Wikimedia things. It has turned fixing something here from a manageable diversion while doing work elsewhere by clicking a few things into: typing and waiting and thinking about obtuse wiki politics lore and reading user talk pages to see if they're the sort of person who will be helpful if asked and asking and waiting for responses and so much more and I have definitely forgotten all about the page I was trying to tidy up by now.

"We want to make it easier for everyone to share what they know." That's not from Wikipedia:About, or Commons:About, their individual scopes are not relevant, it's from https://wikimediafoundation.org/about/, and this change has made it harder to use this tool in pursuit of doing that. "Everyone" is not 7,000 gatekeepers. I do not care that there was a discussion at the village pump here. There is a community here, but this tool isn't the community. This isn't a village, it's a website which works as a media file repository, and it's a Wikimedia website which functions as a tool wot's for repositing medias for using on other Wikimedia projects. It's used for all the other projects, all 300 languages of Wikipedia, there are some hundred-million-plus files uploaded here...but only 7,000 users of the tool have crossed this threshold because it's a a community engagement metric and this is just a tool they use, not a community they're a part of. They're not in the village visiting relatives and going for a pint. Users who mainly focus on maintaining other projects rather than checking out all the meaningful banter at the pump here can't use this tool effectively any more. I do not care if reverting this policy would mean a tiny subset of users, the ones who can click a rollback button or whatever steps they have to take will have to do that more often - if it would make their efforts to maintain this site, KEEPING THIS TOOL USEFUL, not worth their time...it's not a job, they're here by choice, if they want to retire there's a template for that and everything. I just want to be helpful. One cookie (talk) 16:50, 12 February 2024 (UTC)

@One cookie dont know what you are talking about. what do you want to do with those 2 files you linked in the 1st paragraph? anything preventing you from just using whichever file you want? RZuo (talk) 19:01, 12 February 2024 (UTC)

(Not addressing the main point, but might I suggest that we put a link/mention of each file on the other file so that in the future people don't have to do a reverse image search to find out they both exist?) -sche (talk) 19:21, 12 February 2024 (UTC)

Yep, that can be a nice idea. The information template has an "other_versions" parameter for this -- either links, or inside a gallery tag. You can also edit your user preferences under "Gadgets" to add the "Tineye" and "Google Images" tabs on an image page, to make reverse searches easier (and tineye can filter on Wikimedia.org). The other usual way is to look through the categories the image is in (more specific the better) to see if there are other versions of it. Carl Lindberg (talk) 01:50, 13 February 2024 (UTC)

Trying to see if I understand the above. The link to the article in the first paragraph is broken, so not sure which was using the bad image. But I do see we have several versions of that image:

• File:B-25 production Inglewood Oct 1942.jpg pretty small black and white version, but uploaded long ago and probably was used in pages at some point.
• File:North American Aviation plant - B-25 Bombers.jpg Larger, color version
• File:North American Aviation plant, Inglewood, CA.jpg Slightly color adjusted version of the one above, uploaded by the same person a couple weeks later
• File:B-25 final assembly line Inglewood 1942.jpg Very large color but highly JPG-compressed version
• File:View of the B-25 final assembly line at North American Aviation1a35295v.jpg Version scaled down from source version at loc.gov
• File:View of the B-25 final assembly line at North American Aviation's Inglewood, California, plant LCCN2017878501.tif 190 MB archival TIFF version from loc.gov, which is usually the preferred version to start from for someone making edits/crops
• File:B-25 final assembly line at North American Aviation's Inglewood.jpg Very large color-adjusted and cropped version, probably starting from the loc.gov version directly.

If there was a usage of that small grayscale one, by all means edit the Wikipedia article, and change the file reference to the one you prefer. No change needs to be made on Commons. If you want a different crop/coloration, then please upload as a different file, and again edit the Wikipedia article to choose your new upload. There is no action needed (or wanted) on Commons to switch images on Wikipedia articles -- the file reference is in the source text of the article. The links on the image page are all for unrelated operations, none of which you probably want. Correct that there is no merging of images (Commons wants options for projects to choose from). Renaming is pointless (that is only for filenames with errors or some other defined reasons; we try to avoid renaming in most cases). As you guessed, duplicate is only for exact duplicates -- same photo, same crop, same color adjustment, same copyright license. None of the above are duplicates. If you found a better or different version you want to upload, please do -- but do not overwrite; use another filename. We want that new option to be available, but also for projects to choose. If a file is used on two articles or projects, and one project wants to revert while another wants to keep the new one, uploading with the same filename prevents that. Each usage should be able to independently revert per their choices. Overwriting deletes an existing file, basically; we hardly ever want that.

As for your second example, it sounds like you found File:Vickers Vulcan Type 61 G-EBET (148227972) (tight crop, white balanced, grayscale).jpg, and a better/different scan that you then uploaded at File:Vickers Vulcan G-EBET, 1923.jpg because you could not overwrite the first one. The grayscale one itself was extracted from File:Vickers Vulcan Type 61 G-EBET (148227972).jpg, which does look like the exact same image (just lower resolution) than you uploaded. In this case, overwriting the grayscale one (if that was indeed your first instinct) is not a good idea. That is exactly why the new block is here -- the policy, for well over a decade now, is that we do NOT want an overwrite in that situation, as explained earlier -- we want more choices. So if that was your intention, the block prevented you from doing the wrong thing. Nor would we want a direct overwrite of File:Vickers Vulcan Type 61 G-EBET (148227972) (cropped).jpg, as that is also a different crop. However, overwriting the original File:Vickers Vulcan Type 61 G-EBET (148227972).jpg would be fine, as it does appear to be a higher-resolution version of the same scan of the same photo, and there are no copyright differences between them (such as one license on a low-resolution version, and a more restrictive license, or no license at all, on a higher resolution version). So yes, provided you had worked your way back to that source image, that was a correct action which was prevented by the new policy. If your intent was to change the Wikipedia article though, you would have still needed to change the Wikipedia article text to point to that file, same as if you had uploaded with a different filename.

To overwrite the grayscale, you would need to make the same adjustments. Unless you work hard on getting the same exact crop and white balance, it could still be preferable as a separate file. In almost all cases, editing the wikipedia article to point to the new file is a necessary and expected step -- and is more desired as then watchers of the article will be notified of the change, and can discuss there if there is any disagreement. It looks like the other user did that for you on the Vickers Vulcan en-wiki article, but that is something you could have done yourself right after uploading the new version. Notifying other users is certainly nice, but not a requirement. You could add links to the the other crops in the other_versions area of the Information template on the image page so that others viewing it see there are other options, but again not a requirement (though that would tend to notify the original uploaders too, as they would normally have a watch on their file). As long as they are in the same category, other editors can add find them and those links or galleries that too. (For example File:1944 NormandyLST.jpg lists several other scans of the same photo, which all look different -- we don't want to merge or overwrite or anything there; each different scan should be its own file so each project can determine which is best for their usage.) In this case, since you have uploaded under a different file, you could put {{Duplicate}} on File:Vickers Vulcan Type 61 G-EBET (148227972).jpg since that does qualify. Or you could edit the file page to use the {{Superseded}} template so anyone looking at the file knows there's a better version in all respects. None of this requires autopatrol access. When overwriting, you need to make sure it's a near-duplicate in the first place, and be aware of any possible copyright issues. These are often complicated, and not always fully understood, and overwriting should be avoided unless you get familiar with them.

If there is a case where we should replace many usages of a file across many project (Wikipedia and others) with a new file, a request can be posted at User talk:CommonsDelinker/commands.

That all said, we could possibly make this easier for people to do. Right now there is an all-too-tempting "Upload a new version of this file" link for people to use on the image page, but that is what can lead them right into this restriction. A similar link of "Upload a modified version of this file" which starts with a copy of the file page text content, and adds (modified) or something to the filename, while allowing any of the text or filename to be edited might be a nice feature, and lead people down a better path. Carl Lindberg (talk) 01:41, 13 February 2024 (UTC)

Added {{Other versions/B-25 production Inglewood Oct 1942}} to those file pages. Glrx (talk) 05:47, 13 February 2024 (UTC)

Don't argue against individual examples. Even if you're right, proving one example incorrect doesn't negate an argument, that's fallacious.

All of the tagging you suggest would be helpful for people browsing Commons, looking at files, one-by-one. I do not care about that. I pointed out that I do not care about that. I pointed out why I do not care about that. I pointed out why it's pointless, and why being able to tag and add templates and add to categories is inconsequential for my goal. I can see that you've replied elsewhere to people who have the same obvious problems with this policy change, you weren't trying to see if you understood the above. You reframed the argument, and then argued against your new version of it, and started going on about how the examples given didn't apply to your new version of my argument.

I want to be able to improve or fix files hosted on Commons in-situ so that they are fixed where they are in use, outside of Commons. I don't want to suggest an alternative link to people who are browsing Commons reading talk pages, or tag duplicates, or make a new page for a duplicate of an image, fill out all of its tags and rights information, and then individually change the embed on every page on which the bad file features.

Here is a very straightforward example:

• https://commons.wikimedia.org/wiki/File:Weimarer_Republik.png.

I noticed that file had a problem while reading a page on en.wikipedia.org. I fixed it. I uploaded it as a new version of the file.

In doing so I fixed pages on en.wikipedia.org, de.wikipedia.org, mk.wikipedia.org, pnb.wikipedia.org, pt.wikipedia.org and ur.wikipedia.org, all in one go, without ever having to visit those wikis at all, and I can't do that any more.

That is what overwriting files is for -

[OK] As a general rule, use the link "Upload a new version of this file" only for relatively minor improvements. Examples include:

• replacement with higher-resolution versions of the same file, however, without using artificial methods to generate higher resolution
• minor and uncontroversial color correction, noise reduction, perspective correction, etc.
• removal of a watermark
• needful 90/180/270° rotation or minor rotation correction of images that are not upright
• minor cropping
• uncontroversial corrections to diagrams, maps, or charts, if a more accurate version is available
• correction of SVG errors
• adding or correcting translations, fixing spelling errors (e.g. changing "grater" to "greater")

Those are not uncommon problems - so to further repeat myself, out of all users of every language of every wiki site, only 7,000-ish users can solve those problems without having to either go through a multi-step arbitration requiring actual human time, or do it the wrong way - upload a duplicate, use Template:Duplicate to justify a speedy-delete of the original page and the file history, and edit every page the file's used on, individually. Contributing to every wiki has been made more difficult.

Most users who decide uploading a fix isn't worth the time and effort won't come here and write diatribes about this stupidity. They won't go to the Wikimedia village pump. You will never hear from them. They will see that the policy is that they can't help, that they can only ask for help, so they will move along, and they won't contribute.

The lower-resolution duplicate of the photo of the Vulcan is at https://commons.wikimedia.org/wiki/File:Vickers_Vulcan_Type_61_G-EBET_(148227972).jpg. One cookie (talk) 00:00, 19 February 2024 (UTC)

a user who wants to use his/her "correct" version of a file can always simply upload it and then use it on other wmf projects, so none of this analysis about users being stopped is accurate. RZuo (talk) 04:07, 19 February 2024 (UTC)

That is not "simple". All the data and metadata has to all be entered manually, copied and pasted across field by field, every time, which is not simple and takes ages. There isn't a button to copy every bit of information and metadata on a file's page except for the file and use it to make a new page, because if it were that easy, it would result in even more unnecessary duplicate pages (ie, the thing you are suggesting as a solution to the problem that has been created) - do you think it would be good if categories showed every version of every file individually, all at once, in a way which can't be disabled? Thumbnails for high-resolution and low-resolution copies of the same files all next to one another?

If you have OW rights, rather than me uploading it with a new filename and entering all the data and editing the pages on English Wikipedia and Hungarian Wikipedia and Italian Wikipedia and Polish Wikipedia and Portuguese Wikipedia and Turkish Wikipedia and Vietnamese Wikipedia so the images embedded on those pages aren't the old low-resolution version any more, all separately, would you please download the tiff at https://www.history.navy.mil/our-collections/photography/numerical-list-of-images/nhhc-series/nh-series/NH-97000/NH-97885.html, crop it appropriately, save it as a JPEG at quality 10, and upload it as a new version of the file at https://commons.wikimedia.org/wiki/File:USS_Wichita_(CA-45)_underway_during_a_winter_storm_off_Iceland_in_January_1942.jpg?

I'd do it, but I can't. One cookie (talk) 15:34, 11 March 2024 (UTC)

upload and use the tiff. RZuo (talk) 08:31, 12 March 2024 (UTC)

Commons:Overwriting existing files#Substantial crop or un-crop has some guidelines for what users used to be supposed to do in this sort of situation, so what you need to do is replace the file with the tiff and then follow that up by replacing it with your cropped copy. That way, the different file versions are in the "file versions" bit of the file page, and not disparately spread around under awkward slightly-different file names which uselessly won't appear under any single link! And then edit that page, because this change has broken lots of other pre-existing guidelines on it too. One cookie (talk) 02:26, 13 March 2024 (UTC)

File:Felicien Rops, L'idole (1882) heliogravure (27.6 x 20 cm) Michael C. Carlos Museum, Emory University, Atlanta.jpg

This image is a lower-resolution version of the file at its provided source, please upload the source image as a new version One cookie (talk) 11:11, 15 March 2024 (UTC)

They've never replaced the JPEG with the TIFF; it's never been legal to upload a file under an extension that doesn't match its type. TIFF files have always been uploaded separately from any JPEG version.--Prosfilaes (talk) 18:06, 15 March 2024 (UTC)

There are times where an overwrite is appropriate. The problem has been that most overwrites which are actually done, are not. If you think you understand the copyright issues and will keep the overwrites within the guidelines, then please request access to the user group. If you don't want to do that, then you can always upload as a separate file. Instead of copying information field by field, you can use the experienced upload, where you provide the entire file page text, and start with a copy of the one that you are providing an alternative for (just click edit on the image page, and copy all the content). It may be a good idea if we can give people a link to automate that, just as easy as that enticing "upload a new version of this file" link. If you need to replace the image on multiple wikipedias, add a request to User talk:CommonsDelinker/commands. Obviously this is a little harder than simply overwriting the file, but easier than editing each wiki and it should be relatively rare to need it. I don't think anyone is saying there are no legitimate reasons to overwrite a file -- there are. Unfortunately there are also many, many bad reasons to overwrite, and the majority of overwrites were in that area -- ones that were not following the 10+ year old policy, and some were doing a fair bit of damage. The question is how to stop those, and this was the way which seemed actually work. Even longstanding editors, whose habits were set years ago, make these mistakes -- since they seem OK at first blush, treating files like a wiki article, but usually are not. The question is how to stop editors from doing overwrites which don't conform to the guidelines. Carl Lindberg (talk) 20:29, 15 March 2024 (UTC)

"Don't argue against individual examples. Even if you're right, proving one example incorrect doesn't negate an argument, that's fallacious." If there's a reason to offer an example, there's a reason to show that that example doesn't apply.--Prosfilaes (talk) 16:06, 19 February 2024 (UTC)

Ignoratio Elenchi, according to Aristotle, is a fallacy that arises from "ignorance of the nature of refutation". To refute an assertion, Aristotle says we must prove its contradictory; the proof, consequently, of a proposition which stood in any other relation than that to the original, would be an ignoratio elenchi. Since Aristotle, the scope of the fallacy has been extended to include all cases of proving the wrong point ... "I am required to prove a certain conclusion; I prove, not that, but one which is likely to be mistaken for it; in that lies the fallacy ... For instance, instead of proving that 'this person has committed an atrocious fraud', you prove that 'this fraud he is accused of is atrocious'... The nature of the fallacy, then, consists in substituting for a certain issue another which is more or less closely related to it and arguing the substituted issue. The fallacy does not take into account whether the arguments do or do not really support the substituted issue, it only calls attention to the fact that they do not constitute proof of the original one… It is a particularly prevalent and subtle fallacy and it assumes a great variety of forms. But whenever it occurs and whatever form it takes, it is brought about by an assumption that leads the person guilty of it to substitute for a definite subject of inquiry another which is in close relation with it.

— Arthur Ernest Davies, in: "Fallacies" in A Text-Book of Logic

One cookie (talk) 11:20, 15 March 2024 (UTC)

Despite that huge block of text, I stand by my assertion; if you're going to include examples in your arguments, it's reasonable to dispute them. If they don't matter, don't include them. If you argue "this fraud he is accused of is not atrocious", then it's entirely reasonable for people to respond "the fraud he is accused of is indeed atrocious".--Prosfilaes (talk) 18:01, 15 March 2024 (UTC)

Technical guide for overwriting

is there a technical guide about how to overwrite, instead of this policy page explaining why? RZuo (talk) 10:41, 21 February 2024 (UTC)

Remove or move statement.

The following statment disrupts the flow of the information in the Substantial crop or un-crop section.

When cropping a JPEG image, remember to always use lossless cropping.

Personally, I do not think it belongs in this article but if it does it should be somewhere else. User-duck (talk) 05:03, 23 March 2024 (UTC)

Example need copy edit.

• Example: This 1899 portrait of a young man with a fish by Wilhelm von Gloeden was uploaded in 2005 but then overwritten in 2010 by a full length un-cropped version. ...

"a full length un-cropped version" should be linked to an archived version of the file. It has been overwritten a few times since 2010. If the example is intnded to show the history, It should be reworked. User-duck (talk) 05:20, 23 March 2024 (UTC)