陶渊明是什么派诗人
Add topic
|
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.
semi-protected edit request
[edit]In the section: DO NOT overwrite § Exceptions to the minor changes rule
Please change
Digital restoration
to
Digital restoration (of historical documents/artworks)
Emdosis (talk) 06:43, 10 September 2024 (UTC)
(Or alternatively, any uploads that are historically relevant. If they are not, I don't see why digitally restoring an image of a picture of someone's pet for example, should have to be uploaded as a separate upload, especially when the original upload is extremely blurry and/or low quality.) Emdosis (talk) 17:44, 27 March 2025 (UTC)
When in doubt ... upload as a new file.
[edit]I understand the reason for that advice. It would be helpful if the page provided instructions on how to actually do the upload, while respecting the copyright of the original file. Maproom (talk) 07:47, 25 September 2024 (UTC)
Put up barriers against contributions properly
[edit]"Upload a new version" link should not be displayed for those who are deprived of this functionality. You make people discover that overwriting now requires a permission only after going through the process of uploading a new file. Statistics page shows that there are currently 38,024 active users here, and most of them don't have the rights to overwrite. This page also says (in a footnote, for some reason), that "A file can be overwritten by any user with an account older than four days" - this is not true anymore. It should be stated right from the beginning that making minor, guideline-compliant improvements warrants a petition to privileged users.

And I want to note that dragooning the editors into following this guideline in such a restrictive way was necessitated by a single reason - overwriting is a simple and effective tool to solve their tasks. Uploading a new file is so much more problematic (going through the monstrous upload wizard, filling in a description section with a bunch of unknown templates with their rules, choosing a correct licence with its template, adding categories, writing a new filename into all corresponding pages) that editors rightly used the overwrite functionality without ever learning that they might be breaking some Commons guidelines. There is no mechanism to "fork" or supersede a file, taking over its name and/or information without removing the older one (as I see it, the rationale for restriction is that overwrite effectively erases an older, potentially useful file). New uploads are just atrocious from UX standpoint. Wizard forces you to pick a single source and author for multiple files, so you have to manually edit it afterwards; you must enter a specific creation date even if it is not known - once again, you have to edit it manually afterwards and google which template you should use; it lets you fill in what image depicts but doesn't tell you that you should add these entities' categories yourself even if you expect them to be added automatically. Basic upload form (removed by a couple of extra clicks and scary textwalls) is more useful in these "just upload a new file" cases, as it lets you to simply copy the information code, but you still must pick a license from a drop-down menu and add categories manually. And what functionality do we have to group these various versions of similar files? Manually creating galleries under other versions
parameter in each file? Categories? Users are just incentivized to clutter them right now.

You've certainly solved your guideline-breaking problem, but with this decision you've taken away an effective tool from the majority of editors. There is obviously a tradeoff between potential guideline violations and potential useful contributions not made, but as I see it the latter was not even considered in the discussion since it was framed as "guideline-compliant edits vs guideline-breaking edits". I don't hope that people here would say "oh no occasional editors don't now upgrade old tiny blurry images to highres ones, it's too heavy cost for the protection of guideline". I just want to point out that 1) there are certain tasks that overwrite mechanism currently solves best; 2) the effort to educate the editors of its usage restrictions has failed (people use tools for what they actually do, not what they are meant to do); 3) majority of users have no access to a useful tool right now; 4) the decision seems to have been taken without consulting them (maybe I'm wrong and people beyond Commons Village pump were actually invited to participate; maybe it isn't considered necessary here); 5) certain kinds of useful contributions will not be made until a solution arrives. It's easy to undo incorrect overwrites, it's possible to devise a way to undo them in a way that saves both files, but it's not possible to "redo" an edit which was not made at all because of artificial roadblocks. Qbli2mHd (talk) 04:10, 10 February 2025 (UTC)
Users who ignore the policy
[edit]Is there a place to notify about users who are made aware of the policy, but ignore it? Is it enough to remove autopatrol rights? I'm sure most of their other contributions are very helpful. For example, File:Coat of arms of West Virginia.svg was replaced by an entirely different version, and the user persisted after being informed on their talk page. It appears that same user is overwriting File:Great Seal of the United States (reverse).svg, a copyrighted version done long ago by a contributor here, with an entirely different version from another source, breaking the copyright attribute and the like. Carl Lindberg (talk) 01:44, 30 July 2025 (UTC)
What about losslessly recompressed images?
[edit]e.g. by 'optipng' or 'jpegoptim' which don't make any visible change but reduce the file size? --RokerHRO (talk) 19:09, 5 August 2025 (UTC)
- @RokerHRO: For me, compressing and overwriting an image is a hard NO. Use the original JPEG. Any further compression will lose information. Something that is not a visible change to one person may be a visible change to another. The compression will not "save" any storage bits because Commons keeps all versions of a file around; the overwrite is less efficient because it will use more storage. If the further compression is small (say 10 percent), there is little point. If the further compression is large (say >50 percent), then it is much more likely that there are visual changes. Too many editors go on pointless optimization quests that provide no real benefit to Commons and disturb other editors by tickling their watch lists. Glrx (talk) 22:07, 5 August 2025 (UTC)
- jpegoptim can be lossless, so little harm. I don't think this policy should block it. But that said, I tend to agree with Glrx -- there usually isn't much point. It's not saving disk space overall, since the original is still saved and takes up the same disk space as before; we are now taking up the additional space used by the new version as well. The usual reason to use those tools does not exist here. If it makes the resulting jpg faster to process, maybe I could see it, but usually the changes are marginal. Reducing the size of SVGs is often even more pointless -- doesn't necessarily make them any easier to edit or process (though I have seen ones that significantly simplified them and made them easier to edit, so it can make sense on occasion). But, I think they fall under "Minor improvements", so not a reason to disallow them -- this policy exists for other reasons to me. Carl Lindberg (talk) 00:16, 6 August 2025 (UTC)
- Hi, I agree with Glrx. Compressing and overwriting an image is completely useless on Commons. It doesn't save space, only increases space used on the servers. Yann (talk) 17:31, 6 August 2025 (UTC)