Commons talk:Overwriting existing files/Archive 1

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

Mistaken uploads

What about mistaken uploads overwritten with the right image by the original uploader a few seconds after? --ŠJů (talk) 01:39, 11 August 2012 (UTC)

No problem with that, except that the uploader might want to erase the wrong version from the history (e.g. for privacy reasons). Which option gives less publicity to the wrong image? --LPfi (talk) 17:11, 12 August 2012 (UTC)
Can those be {{Split}}? --McZusatz (talk) 17:22, 12 August 2012 (UTC)
Well, when that happens the uploader should clean up the mistake, by requesting revision deletion of the mistaken image, and if necessary uploading the mistaken image elsewhere. If this happens often enough it can be given its own template (modelled on {{Non-free frame revdel}}), and mentioned here (maybe in See also section, as it doesn't fit neatly anywhere else). Otherwise, if it doesn't happen that often, it is only a guideline and doesn't necessarily need to cover every case. Rd232 (talk) 11:24, 13 August 2012 (UTC)

Commons:Village_pump#Commons:Overwriting_existing_files

A discussion about this proposal took place here. Jan Arkesteijn (talk) 18:22, 14 August 2012 (UTC)

RFC

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The conclusion of the RFC is that Commons:Overwriting existing files is enacted as a guideline. Further changes to the guideline can be proposed and made in the usual way. Rd232 (talk) 15:46, 3 October 2012 (UTC)


The previous version of this proposed guideline, Commons:Avoid overwriting existing files, existed with few changes since 2010 (last version before I redirected it here to avoid confusion). Commons:Overwriting existing files is an expanded and clarified version of that. I believe it is now, or will be soon, ready to be an official guideline. Please comment below. Rd232 (talk) 17:09, 14 August 2012 (UTC)

Questions

  •  Question I don't see anything wrong with the changes; they clarify the previous policy. Why do the reactions vary from "{{Support}}. To keep history straight." to "[[[:Template:Oppose|{{Oppose}}]]] I generally agree with this policy, but would like to see the above points addressed. File history is a great way to keep track of... file history, including originals that are or may be useful but which are not the intended final file to upload to Commons. Please keep it that way."? I don't see how history is affected by the new policy. Please try to respond in a possibly short, clear way here. Thanks! Gryllida 05:36, 22 August 2012 (UTC)
  •  Question How would the guidelines adquately handle screenshots of software? Commons:Screenshots policy discourages the use of visuals and elements of proprietary software, such as non-free window decorations around what is otherwise free software (with non-free widgets being acceptable as de minimis on the basis of their unavoidability).
  1. If we take the example of File:Firefox14.png and its upload history, then in all actuality the file deserves a revert to the very first version, because three new versions of the file contain visuals and elements of proprietary software. The first case requires user consensus, because the new version is substantially different and should be in a new file instead. I've had to upload the original as a new file just to make sure it's visible in its respective categories.
  2. In a similar, but different case of File:SeaMonkey2.7.1.png, a new version removing visuals and elements of proprietary software, while keeping the substantial part of the screenshot, should not be reverted. User consent should not be required, because the new version tries to adhere to Commons policy. In the case of this image, my justified attempt of once removing most proprietary elements ended up in a revert to the original (Gah!!) by the original uploader. Such reverts may cause the minor revision to be uploaded as a new image, which is superfluous and takes up unnecessary resources, while it's not at all clear when the original will ever be removed on the basis of its being as non-free as it is. -Mardus (talk) 09:43, 27 August 2012 (UTC)

Approve now

Approve as a guideline now; it's good enough. Any changes needed can be made after discussion in the usual way afterwards.

 Support Looks fine to me. Also support suggestion below that we remind users on the guideline page that w:WP:be bold applies this guideline is mainly for dispute resolution purposes, not a prescriptive instruction manual. Deryck Chan (talk) 09:43, 16 August 2012 (UTC)

Some changes needed

Some changes are needed before it can be approved.

  •  Oppose да кому это мешает вообще. --Михаил Марчук (talk) 15:47, 21 August 2012 (UTC)
  • I think in the situations in which formally only the uploader him/herself is allowed to overwrite, other users might overwrite if and after the uploader has given permission to do so. Though this might be considered as obvious, it might be mentioned as a side note. --Túrelio (talk) 19:36, 14 August 2012 (UTC)
    • That's a bit of a complication... I wouldn't have thought that happens often enough to be an issue. In any case, it is only a guideline, there can be reasonable exceptions especially when they clearly follow the spirit of it. So I'm not against adding it in principle, but I'd prefer to see some indication of this being more than a theoretical issue first. Rd232 (talk) 22:28, 14 August 2012 (UTC)
      • Well, actually, I do this already every now and then, though, I have to admit, often the other way round. I upload a necessary, though often minor improvement and then write to the uploader that he should feel free to revert to his original version if he prefers that. Usually I get an O.k. or a Thank you. @Rd232, you should not misunderstand this proposed addition as a very important thing/change. There was just no other place than "Some changes needed" to add it. It's just common sense put into words. --Túrelio (talk) 06:44, 15 August 2012 (UTC)
    • I agree, especially for cases where the uploader is different than the original source[1]. Unless, "Changes to a file that are likely to be contested should be uploaded to a separate filename." is meant for these types of cases. --Ne0Freedom (talk) 20:35, 23 August 2012 (UTC)
  • Similar doubt as Túrelio. I'm currently uploading a series of scans from a book, which I afterwards improved with Gaussian blur + curves on GIMP to get rid of the moire and to improve contrast and give the looks of a real photo (example). I do not want to upload them as separate files, since it would crowd and clutter the categories without any necessity with raw scans, but I want to upload the original file anyway, in case someone wants to use them (to give a different effect, for instance). So I'm uploading first the original, then my version over it. I do not want to have someone nagging me about that because of this guideline, however, since my original scans, while still possibly useful, are not "historical documents".
  • Similar case as above - I will be uploading shortly a series of old photographs from my family files. I want to place here both the originals and the digitally restored versions, but without cluttering the categories and without duplicating my whole work, so I will do the same as above: Upload first the original as scanned, then the digitally restored version over it. While doing this, I don't want to have to argue with people over this because of this guideline. I could only upload the digitally restored version, since it is me who is releasing the files. The upload of the original is an added bonus, but I don't want double my work because of it. If anyone wants the original, they can simply get it from the file history. If anyone wants to reuse the original, they are free to get it from file history and upload it under a different name (but with same license, of course).
  • I generally agree with this policy, but would like to see the above points addressed. File history is a great way to keep track of... file history, including originals that are or may be useful but which are not the intended final file to upload to Commons. Please keep it that way.-- Darwin Ahoy! 00:12, 15 August 2012 (UTC)
    • Are those cases not covered by Commons:Overwriting_existing_files#Unedited_versions? Does something need to be clarified here? Also, if you have an unedited version example for the Examples section, that would be helpful. Rd232 (talk) 00:39, 15 August 2012 (UTC)
      • Good grief, they are. I'm sorry, I missed that out somehow. I now added {{Unedited version}} to File:Homenagem ao Padre Fernando Augusto da Silva, Santo António, Funchal, 1927.jpg, thanks for the heads up. You may use that file or any other you fancy at Category:Files scanned from books by DarwIn, which I will populate in an hour or so, they will be all "unedited versions" which I have here ready for upload.
      • Now, please look at this case, which just happened a moment ago. File:VIRGEN DE LA LUZ 2.jpg was deleted today due to lack of license. As it was on my watch list and was in use, I looked at it and realized it is an 18th century painting, actually, so restored it and correctly licensed the file. While researching the painting, I found a much better version than the ugly thing the original user had uploaded, and overwrote it with it (since it's hard to believe someone would argue to keep that crap here). Is this allowed according to these guidelines?-- Darwin Ahoy! 01:11, 15 August 2012 (UTC)
        • As I understand it, the VIRGEN case should be handled by uploading as a separate file, and then nominating the old one for deletion. Overwriting a file in this way is close to deletion, and I think the consensus is that deletion policy should be applied here. It's not the biggest deal in the world, IMO, to do it your way, but you did ask :) Thanks for the unedited versions example. PS on an unrelated note, formatting the date this way in the Date field of {{Information}} allows it to be autotranslated. Rd232 (talk) 01:36, 15 August 2012 (UTC)
          • I tend to agree with you about the Virgen case, it was just a quick fix (which I may split and do it properly someday). Thanks for the tip about the date. :) -- Darwin Ahoy! 15:18, 15 August 2012 (UTC)
    • I think that this is already covered by the exception: "Unedited versions replaced by uploader shortly after upload of unedited version" Darkonc (talk) 21:44, 18 August 2012 (UTC)
  • I must say I was totally unaware such a policy existed. I almost never overwrite except to crop images, which are normally of museum objects. If the crop is "minor" I won't bother, so I usually remove over 50% of the original area, but this is just plain background - see for example File:Miyasaka Hakuryu II - Tigress with Two Cubs - Walters 71909.jpg which I've just done. I think the policy should be more carefully worded to distinguish between such cases and other photos. Oh, and by the way, with my own photos I may use overwriting to get photos of the museum label and the object on the same file.Johnbod (talk) 01:03, 15 August 2012 (UTC)
  • Such crops are probably OK. Comparing to the Scorsese example, a similar level of cropping occurs but in one the subject is untouched, but in the other it is. If anyone contests the crop, and wants the wider image with the blank background, then the contested change rule should apply. When cropping plain backgrounds away, problems may occur if the crop is so heavy that the image goes from having a significant border around the subject to having no border at all. Most people would expect a reasonable border to be there. I'd read "minor crop" as "crop not affecting the composition", not "less than 5/10/20% of image removed"--Nilfanion (talk) 01:18, 15 August 2012 (UTC)
  • Added your example, hope the result is OK. Feel free to tinker. Rd232 (talk) 01:27, 15 August 2012 (UTC)
I've added your mountain example, which is a nice contrast to the existing Scorsese one. I'm less sure about referring to the "main subject of the image" - I think that may encourage people to overwrite when a separate file would be better. For instance, even though it's only sky removed, I'm not entirely convinced about your bird example - it's borderline, but I'm not sure the crop shouldn't have been a separate file. Rd232 (talk) 13:54, 15 August 2012 (UTC)
Agree, but this affects all crops, whether removing a one-pixel border, or a substantial amount. If for example using Photoshop to do the cropping, always save at 'Maximum' (12) quality to preserve all the detail in the retained part of the image. - MPF (talk) 10:15, 15 August 2012 (UTC)
  • Some expansion of the exceptions would be good. Firstly - Its not solely Commons status that matters, if an image is featured on any project it should be covered, for the same reason. Would former FPs also be covered? It might be useful to use SVGs for some examples: Correcting spelling on a map's labels is clearly an acceptable update. Translating the map's labels from English to German is clearly not OK.--Nilfanion (talk) 01:04, 15 August 2012 (UTC)
  • I'd like for the policy to address revert/upload warring. Take, for example, File:Kit_body_rmcf1213a.png. That one went through two seperate but related upload wars, one on 21 July and one on 22 July. That's really, really disruptive, and this policy would be the best place to handle it. Sven Manguard Wha? 01:46, 15 August 2012 (UTC)
  • Can we promote the idea of using templates like {{Preview Crop}} instead of making a new image every time someone wants to use part of a photo? I know it's not a good idea in every case, but for transitional project pages or for a brief illustration for discussion, this is a handy alternative. --Fæ (talk) 15:40, 15 August 2012 (UTC)
    • "templates like" - are there others? No harm in adding that one to See also. It's also possible that we should have a little help page just about cropping (Commons:Cropping images?), to give a quick overview of crop issues and tools. Rd232 (talk) 17:19, 15 August 2012 (UTC)
      • I am not sure I know of all templates on Commons (;-)), off the top of my head things like {{Superimpose}} might be alternatives to creating new derivatives that are unlikely to get high levels of use. I don't know what other templates might do similarly clever manipulation. --Fæ (talk) 22:22, 15 August 2012 (UTC)
  • Notification is a key problem, there should be some guidance on which scenarios require someone to notify either the uploader or instances of use before making changes. --Fæ (talk) 15:40, 15 August 2012 (UTC)
    • I'm not aware of any consensus on notification. I suppose the {{Current}} template falls into or near this ballpark (warning reusers that changes may be made), but it's not actually notification. Rd232 (talk) 17:19, 15 August 2012 (UTC)
      • We really could do with some guidelines, and consensus, in this area. We have past examples where simple digital restoration changes a historic battlefield image into one where you can see dead bodies, or a simple un-cropping makes a photograph sexual whereas previously it was ambiguous. Although you might think such changes would be thought of as 'significant', the person uploading an improved image may not realize the impact they might have where the image is automatically trascluded. --Fæ (talk) 22:22, 15 August 2012 (UTC)
        • Well, notification is surely beyond the scope of this RFC. Those examples, if you can find them again, might be useful for the Examples section. Rd232 (talk) 10:01, 16 August 2012 (UTC)
  • I do not understand why files with a marked special status should never be improved - even pictures of the year at times could merit it, in particular images which have been retouched, specifically because they were retouched. In particular this image from 2008 comes to mind - see where the other horse was? It's a lovely image, but there do remain visible signs of the other horse's removal in the horizon, behind one's the tail, and particular on the groundline under the tail. Should someone decide to clean that up, why in the world should it have to be uploaded as a new file when it is maintaining the intent of the assessment of the image? Now I admit this is unusual, but Quality and Valued images are in much greater abundance as well as having more lax criteria for selection, and it is not impossible that much the same could occur on those; Valued images are chosen for what they are, so if someone finds, say, a higher-res scan of the same image and of comparable quality, that should hardly affect the valued status or visa versa, and Quality images are just that - quality, either technical or in terms of what they are, and as such there are similar changes that can be made that would have no bearing on this, same as with any other pictures. Given that any nontrivial retouching of an existing image (barring exceptions already mentioned) should be uploaded as a separate file regardless of its status, the notion that special status files must never be modified at all seems excessive to me when keeping in line with this should have little to no bearing on the statuses themselves. That folks should take more care than in general when working with them, however, is not in question. -— Isarra ༆ 15:54, 15 August 2012 (UTC)
    • I don't deal with FP/QI/VI at all. Maybe there are cases where overwriting such images is justifiable, but I would think it best if at least there is a specific consensus in each case before hand ("I want to do X to this image - shall I overwrite or upload separately?"), reached on the relevant talk page and notified to the relevant Commons project. But really people who deal with these processes should comment on this. Rd232 (talk) 17:23, 15 August 2012 (UTC)
  • I have a question. I shoot a lot of museum artefacts. My first pics date back to 2005 or so; my technique and equipment have improved since then. As a result, I often shoot an artefact I have already shot before, and overwrite my older version with a new one offering a larger resolution and depth of field, and better noise and colour management—composition and aspect ratio are as close as possible to the older version (see for instance File:Worshipper Larsa Louvre AO15704.jpg). Would this be acceptable under the new guideline? Jastrow (Λέγετε) 18:51, 15 August 2012 (UTC)
    • Well, that's an edge case. It is just a guideline, not a manual, and will need some interpretation in practice, based on experience and community discussion of real cases (the Examples section will hopefully grow over time so we have a better picture of how the guideline works in practice). For me, my personal opinion, if you're getting pretty close to the new version just being straightforwardly a higher-resolution version with minor improvements, then an overwrite is OK, given that you're the original uploader. Rd232 (talk) 20:53, 15 August 2012 (UTC)
  • When I want a cropped Version of a flickr image I usually use Flickr upload bot to upload the original a second time, like this no flickr review is nessesary. Than I crop ist and link the full size commons version additionally in "other versions". I think this is a better solution than the alternatives to get correct License information. --Kersti (talk) 22:52, 15 August 2012 (UTC)
  • Cropped Version to have a suitable imgage for the Psittacidae gallery
    Cropped Version to have a suitable imgage for the Psittacidae gallery
  • original
    original

Both are uploaded with flickr upload bot and the file history proves, that the given License was given in Flickr, when the picture was uploaded. So the pictures are not in danger to be deleted, when the Autor changes the license later or deletes his account with all pictures.

Bcause of this prove it is a good Idea to upload pictures with flickr upload bot a second time, if one wants to crop them. This is a good reason to have the original in the file history.

Kersti (talk) 10:44, 20 August 2012 (UTC)

OK, I see - you wanted to crop File:Psilopsiagon aymara -Capilla del Monte -four-8.jpg and instead of just linking to the original, you reuploaded it from the Flickr source so it's part of the file history at File:Periquitos - Psilopsiagon aymara.jpg. I suppose that's fine, and may be clearer to users, but I the other file can also be relied on to provide the necessary license information (eg if the original Flickr source is gone). Rd232 (talk) 14:21, 20 August 2012 (UTC)
  • Clarification needed To me it seems contradictory to say that it's ok to upload "minor improvements" over the existing file but then say "except for controversial or contested changes".
    • If a change is genuinely a "minor improvement", why would it be controversial or contested?
    • This wording is of no help to someone trying to decide how to upload what they think is a "minor improvement"; they can't know in advance whether overwriting will be "controversial or contested".
I edit the English Wikipedia, mostly plant articles. When looking for images, I often see plant images in Commons which should have had colour correction before uploading. (The classic problem is a digital camera set to Auto White Balance making an image with a lot of greenery too purple in an attempt to "compensate".) If I correct this, and the correction shows up in every article which uses that image, then I think I've done the community a service. Uploading a new image doesn't have the same effect: the editors of the Wikipedia articles don't know that the new image exists which could replace the one they used. Simple colour correction should be allowed and not subject to some test of whether it might be controversial or contested. Peter coxhead (talk) 09:41, 20 August 2012 (UTC)
"controversial or contested" is a phrase with two parts. "controversial" is intended to be something understandable before the fact - this might well cause controversy. "Contested" is intended to be understood after the fact - someone objected, and discussion could not resolve the issue. Colour correction is unlikely to be controversial (unless it's really dramatic, perhaps), and that's why it's given as an example under minor improvements. Rd232 (talk) 14:26, 20 August 2012 (UTC)
Here's an example: I rotated File:Coruja Buraqueira na praia 13.jpg to be upright, as per the guidelines and expecting this to be completely uncontroversial. But the original uploader objected and reverted to the tilted original (see image history); I challenged this revertion (User talk:Tm#File:Coruja Buraqueira na praia 13.jpg); in response, the original uploader failed to give any reasons for objecting, but did upload the straightened version as a new file File:Coruja Buraqueira na praia 13 (rotate upright.).jpg. I still fail to see any need for keeping the tilted original, though (should it be nominated for deletion??). - MPF (talk) 16:52, 21 August 2012 (UTC)
So you want to delete a photograph and replace it with a non-photograph? I have deep concerns about things that look like photographs, but have areas that were completely drawn in. Besides which, JPEG recompression means that the original is the best source to work from; if someone wants to rotate that another 1 degree, it should be done from the original, not the new one.--Prosfilaes (talk) 18:16, 21 August 2012 (UTC)
No; I wasn't sure, and was asking; your comments convince me it shouldn't be deleted (though the 'original' - almost certainly a crop, not a true original - is also available at Flickr). I guess what I really meant to ask was 'should the uploader's choice to keep the tilted version as a separate file rather than file history, be overridden or not?' - MPF (talk) 23:32, 21 August 2012 (UTC)
In this example it's irrelevant that the reverter was the original uploader; many contributors would have done that and the original uploader doesn't formally have any more right to revert (though we may often choose to respect their opinion more than that of random passersby). In this case you didn't just rotate an image in a standard "that's on its side" Rotatebot sort of way. As your edit summary said, rotate upright, clone-fill background at corners. That seems worth doing for this image, but it's never going to be a case for overwriting the original. Rd232 (talk) 23:58, 21 August 2012 (UTC)
So just to make sure, I hope you have figured out that it would not be a good idea to delete the original crooked one. Besides, I happen to like the crooked one better - it is lined up on the owl. Delphi234 (talk) 23:47, 26 August 2012 (UTC)

Maps, other data updates, and error corrections

I've created {{Current}} with maps in mind, though I'm sure it works for some other cases too. Rd232 (talk) 14:58, 15 August 2012 (UTC)
Personally, I believe that ANY map, flag, international organization membership, etc. should be updated to current reality unless the file name contains an explicit date, eg File:Flag of Canada 1921.svg, or a particular situation, eg File:Flag-map of the allied-occupied Germany.svg. Updates to current reality need to be the default for files not named more specifically. Vanisaac (talk) 07:58, 16 August 2012 (UTC)
The "updateable files" section is worded quite generally, so there is room in principle for that. But only experience will tell how people interpret the guideline. Rd232 (talk) 20:25, 16 August 2012 (UTC)
I find {{Current}} as default for maps and flags without date (or similar) sounds reasonable, but this should be noted in Commons:File naming. --LPfi (talk) 09:26, 17 August 2012 (UTC)
Not sure what you mean. Perhaps propose something at Commons talk:File naming? Rd232 (talk) 09:54, 17 August 2012 (UTC)
While I agree that some maps are considered updatable, e.g. the tropical cyclone track maps (e.g. File:Lee 2011 track.png, File:13L 2011 5day.gif or File:JTWC wp0811.gif) and time specific versions like File:Megi 2010 JTWC forecast Oct 19 Wp1510.gif are uploaded seperately most maps should be changed only marginally under all circumstances. When last year the South Sudan seceded from the Sudan there was a confusing way of updating and reverting back. Many articles for some time showed wrong versions, depending on which version was up and on what status they were referring to. --Matthiasb (talk) 12:53, 19 August 2012 (UTC)
PS: Though my update of File:Guilderlandcenter.jpg was a major modification I won't consider that one as not appreciated. --Matthiasb (talk) 13:08, 19 August 2012 (UTC)
  • I think SVGs may need to be treated more like text and enhancement in general needs to be allowed. Examples, addition of illustrations to a set, correction of SVG features, removal of certain features to support other uses (eg. PDF that may need to be free of gradients), introduce new approaches for localization of text labels, layout changes and corrections to labels. Shyamal (talk) 08:20, 15 August 2012 (UTC)
  • While should be common sense, it should be noted that this guide should be only enforced in case of disagreements and not just because it's a guideline. There are other examples like Commons:Bots/Requests/UKBot, which only updates Wiki-statistics of particular users. Especially community-approved bots and tasks should be excluded from the guideline. -- Rillke(q?) 11:26, 15 August 2012 (UTC)
  • Similar to what Shyamal and Nilfanion said above I miss a rule for fixing errors in images. Examples:
    1. File:Wappen durrhennersdorf.png, File:Wappen sornzig ablass.png, …: These are bad versions of coat of arms created by users with no experience in heraldry. It should be allowed to upload a fixed version, no matter how old the original version is and no matter who created it. It's public domain anyway. And (that's the important part) no matter how minor or major the change is. The old version is wrong and will be deleted anyway. Why not simply use the old file name? This applies to both pixel images as well as vector versions.
    2. File:Adele Schopenhauer Scherenschnitt.svg: I added more details to a bad traced vector version. This should be allowed no matter how old the original version is.
    3. File:Frankenthal Gemeindeverwaltung 2010.jpg: I had the feeling my original upload was “photoshopped” to much and I did a better edit. Obviously only the original uploader should be allowed to do this. --TMg 13:09, 15 August 2012 (UTC)
    • Sorry, but I've seen too many disagreements about coats of arms to condone uploading of non-minor error corrections. Upload as a separate file, and if necessary nominate the old one for deletion. Remember User:CommonsDelinker can do mass replacements if needed. Rd232 (talk) 14:58, 15 August 2012 (UTC)
      • I'm not talking about controversial edits. In the end I don't care if you add this case to this page or not. If nobody disagrees and the wrong images needs to be deleted anyway I (and other users) will continue doing error corrections in images. No matter if it's explicitly allowed by this page or not. It's a guideline, not a law. It would be nice if you can add something like "there may be many cases like fixing non-controversial errors in images that are not explicitly covered by these guidelines " to the page. --TMg 15:53, 15 August 2012 (UTC)
        • Well, I've added a mention of error correction under "minor improvements". (It's quite general, because it's a guideline and we want to allow room for judgement.) Rd232 (talk) 17:03, 15 August 2012 (UTC)
      • PS: Maybe I'm just confused. There is already a "higher resolution" rule but it's in the "minor" section. I think this clearly applies to the "higher resolution" rule. But it isn't a "minor" change, or is it? Could you move the "higher resolution" rule to the "major change, except for" section? --TMg 16:06, 15 August 2012 (UTC)
        • A higher-res version of the same image (even when it's dramatically higher resolution, as in your example), is a minor change, because nobody should be able to object to it. I've added your example to the Examples section. Rd232 (talk) 17:09, 15 August 2012 (UTC)
  • I think Images on Wikimedia Commons should primarily be seen for their encylopaedic value. There should be no requirement for the original image to be kept on Commons if the original image can be found on another site or in a library or archive. I have had some discussions with some Commons users/admins who seem to think that the whole workflow from original image to crop to colour fixes in the case of old images need to be on Commons as separate files. There needs to be exception where original images (when fixes are made to enhance encylopaedic value) can be found elsewhere / even in the file history. Shyamal (talk) 11:54, 18 August 2012 (UTC)
    • Commons does not serve merely Wikipedia; encyclopedic value is not the end-all and be-all of our goals. I think the WP:V by analogy should lead us to keep the original image on Commons; we want to be able to show our work on it. And as a purely practical matter, other sites disappear all the time, and even libraries or archives we feel we can trust to exist in the future seem to feel compelled to relocate all their content to different places on a different server.--Prosfilaes (talk) 12:31, 18 August 2012 (UTC)
    • I agree with Shyamal. By the nature of Commons, it is not an archive that is able to guarantee preservation of files. Besides, I estimate that the lifetime of Commons could be far less than the lifetime of a real archive. Jan Arkesteijn (talk) 15:45, 18 August 2012 (UTC)
      • With regard to "nature", remember that deleted files are not actually "gone", only removed from view. In my discussions with the British Library, we discussed the nature of their role as a digital legal deposit and the potential for a future partnership where Wikimedia might provide regular archives of the contents of projects as a permanent digital preservation for research. Several such partnerships would enable Commons to fulfil that part of our purpose that is currently weakly defined, that of preservation. It is "all talk" at the moment, but if we could construct a credible 100 year plan, then even if Commons were superseded by something better in a few years time, the archive would persist indefinitely and more reliably than the majority of archives (which tend to lack any reliable planning or budget covering more than 10 years). --Fæ (talk) 16:00, 18 August 2012 (UTC)
      • The lifetime of Commons will not end in the lifetime of Commons; so long as we on Commons need those files, Commons will be here.--Prosfilaes (talk) 20:19, 18 August 2012 (UTC)
        • Indeed, Wikimedia Commons image usage goes beyond encylopaedia value, although by its origins the greatest usage is via the language Wikipedias (although I do remember seeing some admins deleting images of people or pets where they did not see utility). If archival is indeed a requirement, then there should be definite plan for supporting TIF and JPEG2000. Right now I believe there is no support for thumbnail generation from these formats (not to mention fairly straightforward issues like the failure of thumbnailing animated PNGs). Regarding "we want to be able to show our work on it" - it would be very difficult to tell if work was done on-wiki or off-wiki even if we knew anything about the integrity of the so-called "original". Shyamal (talk)
  • I think the proposal misses the case when uploads are made to correct the copyright situation. See for instance the crossed files at Commons:Deletion_requests/Files_in_Category:Stfp.net. It didn't make sense (both in relation to the deletion request and in relation to the use of files) to upload the new files under a new name. Deleting the old files (with clear names) would have prompted CommonsDelinker to delete their uses, creating the need for many reverts in all the projects using the images.--Strainu (talk) 12:24, 20 August 2012 (UTC)
    • No, the case is covered - separate files should be uploaded separately. If files need deleting for copyright reasons when there's a good replacement available, the uses can be replaced before deletion (using CommonsDelinker). If you want to make a case for an exception to the "don't overwrite separate files" principle in some cases like these, fine, but that should be a proposed amendment once this guideline is approved, because it will need wider discussion, and proposed here and now it's unlikely to get enough input. Rd232 (talk) 14:04, 20 August 2012 (UTC)
  •  Oppose. Generally, I like the idea to have such a policy. But Rd232’s project is focused on photographic images and does not address concerns about diagrams. Such conflicts as in w:Talk:Logical connective #Style of Venn diagrams will likely lead to spawning of hundreds of unnecessary files, in accordance to this guideline. Though, I would support for such guideline about photographs (including scans), screenshots, and various scientific and technical data represented as a raster graphics, but excluding diagrams, geometric and technical drawings, icons or so. Incnis Mrsi (talk) 15:03, 21 August 2012 (UTC)
    • I rather see that as a feature; let's not have edit wars over a diagram in Commons should be red or green.--Prosfilaes (talk) 18:16, 21 August 2012 (UTC)
    • Um, you may be able to make a case that diagrams sometimes need special treatment, and if you have more examples we can talk about those. But your example given above is you wanting to overwrite red-colour diagrams with violet-colour versions, because ... well it's not entirely clear why you want to overwrite the existing files instead of upload new ones, but there's a vague sense of wanting to avoid a proliferation of different colour versions. Which is reasonable as an objective, but absolutely not a justification for overwriting here. Rd232 (talk) 23:51, 21 August 2012 (UTC)
  •  Oppose Unless the wording is changed about updates, to editors can add "current" if they choose to identify files that are expected to change. I do not think it should be a requirement. For example, the star identifying featured articles was changed twice over the course of that many years, each time by a different editor who simply thought it would be an improvement. I maintain a large number of data diagrams, some that obviously need to be retained as they were at the time, some that it is a pain in the neck to edit each article that uses them when the data changes. For example, the file name for File:World energy consumption by fuel 1990-2035 EIA 2011.png clearly indicates that is what the projection was in 2011, but the file name File:World energy consumption outlook.png was chosen to be generic, and while I uploaded 17 versions from as many editions of the IEO, from 1995 to 2011, that was done so that if anyone wanted to see the progression they could, but over the next forever I fully expect myself or someone else to upload a new version as it becomes available, and I certainly see no reason for cluttering up the file with a "current" template. This is a wiki for goodness sakes. If someone does not like a file being replaced it only takes two clicks to restore it to the original (or is it one), and if you want to be polite, you can split off the newer data to a new file with a new file name. Here is an obvious point. You say you created the "current" template for this purpose, well did you also go back and add the template to the millions of files that it applies to, and does the policy require that no file created before the template was created can be updated unless someone goes back and adds the template first? Make use of the template optional, and point out that it can also be accomplished by using a generic file name as I did. And yes I think that anyone who wants should be able to upload a new image called Cow.jpg just because they like theirs better. Add that to the section on generic file names. Delphi234 (talk) 22:01, 26 August 2012 (UTC)
    • So if you have a disagreement with someone on the English Wikipedia on what picture to use for a cow, instead of disagreeing with them in an environment where they feel comfortable, silently (from the WP perspective) change the picture on a site they may never have seen? Even if that changes it on sites that describe it as a brown Jersey cow even after you've changed it to a white Holstein cow? This is not the place to have edit-wars over Wikipedia content.
    • One of the huge problems with uploading over old content is that new files get new metadata. We've seen a lot of files uploaded over old ones that have no new metadata, and it's hard to find because the file page still tells you that it's a CC-BY file from Flikr when it's an all-rights-reserved file or a CC-BY-SA file from somewhere else (which is just as much a copyright infringement.) And if it gets reverted back, then the editor has to remember to manually revert the metadata or they will be out of sync, which again can be a copyright infringement.
    • There are images that need "current" attached. It's hardly millions; I suspect it's more like one in a hundred files. As you see them, attach the template.--Prosfilaes (talk) 00:21, 27 August 2012 (UTC)
      • Uh, I already said I had no interest in adding "current" to my own files that I know are going to be updated, why would I add it to anyone else's? I think it should be clarified that it is an optional template, and not a requirement. You are correct it might not be millions, but certainly thousands seems more plausible than hundreds. The point is that editors need to use judgement instead of just looking to see if there is a template. This is not a totalitarian regime. While I fully agree with "Don't be bold", I also agree with using best judgement. The presence or absence of a template has nothing to do with what should or should not be done. Delphi234 (talk) 01:41, 27 August 2012 (UTC)
      • Sorry, I misread hundreds. One in a hundred files out of a hundred million files would be a million. Delphi234 (talk) 01:44, 27 August 2012 (UTC)
      • Or to be specific one out of a hundred of 105,306,644 would be over a hundred thousand. Delphi234 (talk) 01:46, 27 August 2012 (UTC)
      • By the way, in the section, Do change, the files with current data section gives three indications of files that are expected to be updated: "Identification may be by the filename, file description, or (most clearly) with the {{Current}} template." Yet in the gallery, three examples of using the current template are given. I would suggest making sure that all three methods are represented - one with a file name of a file that is obvious that it should be updated, one with a file description that it might be updated, and one with the current template. Delphi234 (talk) 04:29, 27 August 2012 (UTC)
        • I take your point, and I've added a couple more examples; but remember the {{Current}} template may be added at any time to these cases! Using the template isn't necessary, but it's helpful because it's really clear, and translatable (indications in filenames are not translatable), and manual comments in file descriptions may not be as clear about it. Rd232 (talk) 23:35, 29 August 2012 (UTC)

Oppose in principle

This isn't needed, or should be handled as part of another page.

  •  Oppose No, when you overwrite a file that has fortuitous the same name, what then? Wolf Lambert (talk) 16:00, 29 August 2012 (UTC)
    • I suggest you write your comment in your native language (Dutch, I guess from your userpage), because it's not at all clear how your comment translates into opposing the guideline. Rd232 (talk) 16:08, 29 August 2012 (UTC)
  •  Oppose More bureaucracy: this guideline will not prevent or reduce overwrites. It can only by used to cut off a discussion if an overwrite is reverted. To prevent overwrites the description of a file should carry an uploader-motivated message why not to overwrite that file, similar to the warnings we show in the upload-procedure not to upload copyrighted material. Jan Arkesteijn (talk) 17:50, 14 August 2012 (UTC)
    • A warning template applied to 12 million+ files, but no page the template can point to for clarification, so it has to contain the entire text of this guideline? I think you're on your own on that one. Rd232 (talk) 17:55, 14 August 2012 (UTC)
      • You don´t want to understand me, I know, so you simply contort my words. Jan Arkesteijn (talk) 18:17, 14 August 2012 (UTC)
        • Sometimes the same photo can be cropped or the image sharpened with modern technology and to avoid duplication clogging up the wikimedia pages, the author (and ONLY the author) should retain the option of overwriting the proginal inferior photo. Jus' my opinion Meriden.triumph (talk) 19:00, 14 August 2012 (UTC)
          • I disagree; just as on Wikipedia, where no one owns an article, nobody owns a file on Commons (simply because they are all released under a free licence), and everyone should be allowed to overwrite files if such a need arises; especially when the edits are only small (like sharpening). When it comes to bigger edits (like cropping out half of the original photo), however, one should upload the edited version into a file on its own. The current version of the guideline includes this quite reasonable approach. odder (talk) 20:11, 14 August 2012 (UTC)
See above - what if the 50% is museum display case background? Johnbod (talk) 01:08, 15 August 2012 (UTC)
Currently happens that user can crop whatever he/she wants and overwrite. If original uploader or anybody else reverts and/or complains, get stuck in revert war with obnoxios cropping user. E.g. image is bust on post which holds plate with name of person it depicts. Obnoxios cropping user crops out plate, as bust alone is somehow "better" or "only worth of showing". This guideline is intended to squash obnoxios cropping users like bugs, not normal people who crop garbage out of pics. At least I see it that way, do correct me if I got it wrong. SpeedyGonsales (talk) 07:34, 16 August 2012 (UTC)
Whilst you're correct about the intended outcome (cropping out a display plate/label should normally be a separate file), the tone is completely wrong. The guideline is intended to educate users about good practice and help resolve conflicts. Rd232 (talk) 16:37, 16 August 2012 (UTC)
Exaggeration is intended as above cropping example sadly is not my imagination, but something that happened here (on commons) not once or twice. This guideline should alleviate such problems, as total prevention is not possible nor wanted. Congrats for appropriate reaction on tone of my above edit, it is well deserved. :) SpeedyGonsales (talk) 22:03, 16 August 2012 (UTC)
    • @Jan Arkesteijn, so what you mean is not a template, but a sort of note in the upload mask or process, right? --Túrelio (talk) 20:01, 14 August 2012 (UTC)
      • I favor both. A template that produces a message like: "Don't overwrite this file with a better version. It is used to show the decay in image quality of low resolution copies of digital images" or "... It is used to demonstrate the effect of not holding the camera horizontal when taking pictures", or whatever is the reason the image is used for. Anyone can include it in the description of a file-page if he uses a file in a project in a certain way. Combine that with a question in the upload procedure, "Do you object to your image being overwritten with a better version? If yes, give a motivated reason." That is all we need, it is very specific and it will prevent overwrites, instead of this guideline which will only give a non-specific reason to revert overwrites without debate. The positive side-effect is that the quality of uploads will improve, because it will make people reconsider why they would upload yet another picture of mediocrity. Jan Arkesteijn (talk) 09:06, 15 August 2012 (UTC)
        • You still fundamentally don't understand that uploads don't belong to the uploader, they belong to the community which may be using the upload. The uploader can't say "if X and Y, then feel free to overwrite", if that would go against the needs of reusers. Rd232 (talk) 13:08, 15 August 2012 (UTC)
          • You don't read very well, do you? I do understand the rights uploader have or don't have, and I don't understand why you use the word "still"? If you would read my words another time you would see that these messages refer to the usage on projects. These files are in use as such, so there is a reason to not overwrite them. Jan Arkesteijn (talk) 13:45, 15 August 2012 (UTC)
            • OK, yes, you did say the template was to be applied when used "in a project in a certain way". But you followed that up by suggesting we ask the uploader during the upload process "Do you object to your image being overwritten with a better version? If yes, give a motivated reason." Maybe you meant that "motivation" to be based on uses of the file, which anyone could add later, but it didn't sound like it to me. Rd232 (talk) 14:02, 15 August 2012 (UTC)
              • If it didn't sound like that, I'm sorry, but you got it finally right, so it does not seem so unclear. If an uploaders adds a file to use in a project and it is important it stays in that state, he can add a motivation there. Jan Arkesteijn (talk) 14:16, 15 August 2012 (UTC)
      • You might think so, but in our discussion at VP he didn't seem particularly happy about my submitting Bugzilla:39344. Rd232 (talk) 22:32, 14 August 2012 (UTC)
I think most people who are willing to collaborate on Wikipedia, especially on Commons, are people who make an exact pattern in real life, all have a passionate attachment to the bureaucracy. The more bureaucracy, more difficult to sell easily, better. Rules, rules and regulations, preferably increasingly complicated. This is the world of dreams of many who work here. Cheers. MachoCarioca (talk) 07:10, 23 August 2012 (UTC)
It seems a strange viewpoint to me to think of Commons more bureaucratic than Wikipedia and I do wonder how you reach such a conclusion. With so few active admins and bureaucrats helping to run this project (I think one tenth the number of active admins compared to en.wp), it is amazing it does so well with hardly any bureaucracy. From my personal viewpoint, the only real "rules" around here are related to copyright and some moral guidelines, pretty much the rest can be treated as 'ignore all rules and just get on with uploading re-usable free media', including this guideline, unless you fail to be mellow and start disrupting the project and spoiling the enjoyment of others to contribute, and even then your level of disruption has to become outlandishly extreme for anyone to take action. In essence, this guideline only exists to help folks understand that they need to stay mellow and discuss problems that might occur when they have to collaborate when overwriting files - though you can always just create a new image file and avoid the fuss of collaborating or thinking very much about this guideline. In comparison, the English Wikipedia is a wiki-lawyer's paradise. --Fæ (talk) 09:34, 23 August 2012 (UTC)
  •  Oppose Seems like unnecessary fuss. I overwrite sometimes and think that if the original uploader or someone else dislikes it will probably be undone and I can upload as a new file (or the person disagreeing can do it, as has happened to me before). Otherwise it is likely nobody cares so it was probably not a bad overwrite. --Lead holder (talk) 21:30, 30 August 2012 (UTC)

Uploader's decision

 Comment I would also welcome a guideline that the ultimate decision whether a modification is minor (upload over same file) or major (upload as separate file) rests with the original uploader. I appreciate that the way I handled archival versions (not only unedited versions but also intermediate versions in complex restorations) has been adopted into the guideline, but I had edit wars in the past where other editors, admins included, reverted my modification with the (unsupported) claim that this is not the way to proceed with restored images. By giving the original uploader the final say we reestablish the approeciation due to those editors who put considerable effort into finding, researching and restoring original and historical content, something that at times has been sorely lacking within Commons. ~ trialsanderrors (talk) 18:30, 15 August 2012 (UTC)

I suspect that much of that is addressed by writing down how to handle those cases (which I think we've now done here), and labelling them with templates so people are aware. I'd suggest waiting a while after approval of this guideline (a few months?) to see whether that's the case, because I'm not sure agreeing on what you suggest will be easy, and it may cause unforeseen problems if it is agreed. Rd232 (talk) 20:45, 15 August 2012 (UTC)
I actually think that the resolution mechanism for this potential dispute is exactly what's missing from the guideline. It treats "minor" and "major" modification as if there is a clear-cut line between them, From personal experience all over Wikipedia there is never such a clear-cut line on anything. So while this guideline is a very useful attempt to help editors decide on where to upload their files, it does nothing to help settle potential conflicts. ~ trialsanderrors (talk) 21:40, 15 August 2012 (UTC)
But there's a whole "in case of dispute, upload as a separate file" thread running through the page, which if followed stops upload wars at least, and allows discussion on talk pages or deletion discussions. Being clear about that is very much intended to help stop conflicts that arise being damaging, even if it can't stop people disagreeing about what should happen in the first place. Rd232 (talk) 23:54, 15 August 2012 (UTC)
But that is exactly my point. When I upload original and intermittent versions of an image, I do this as a service to the community. When an overly aggressive editor decides now that my restoration constitutes "major changes" and reverts to the original, this guideline provides clearly contradictory statements regarding this case and in the end ("When in doubt, or to resolve inter-user conflicts, upload as a new file") sides with the interloping editor. This has happened to me before, and this is a major reason why I drastically curbed my upload activity. ~ trialsanderrors (talk) 08:29, 16 August 2012 (UTC)
It's a wiki; there should be no uploader's rights, and no editor is interloping. "Cleanup with spot healing brush (80%) and clone stamp (20%)" is major modification; it should not be treated as if it were the same file as the original. If it concerns you that someone would do this, save time and upload two different files to begin with.--Prosfilaes (talk) 09:03, 16 August 2012 (UTC)
Why is it a problem if someone disagrees about whether your changes are major? If you can't persuade the other person, just upload as a separate file, and if need be replace any file uses in projects manually or with CommonsDelinker. I completely understand a certain possessiveness about one's own uploads, but if you can just let go of that, there's really no problem here. PS when you uploaded that example in 2009, were you aware of the same image uploaded in 2005 as File:Lange-MigrantMother02.jpg? Rd232 (talk) 09:58, 16 August 2012 (UTC)
You both are now just confirming my initial contention that this community severely lacks respect for the uploader. And yes, I was: Commons:Deletion_requests/File:Migrant_Mother_(LOC_fsa.8b29516).jpg. This is not a matter of "possessiveness", as you like to dismissively call it, it is a matter of someone putting a couple of hours of work into something vs. someone spending a few seconds on erasing it. Re: Prosfilaes, the alternative is that that I do not upload the original (or the edited version for that matter) at all if the only payoff is that I have to deal with people of your ilk. ~ trialsanderrors (talk) 10:23, 16 August 2012 (UTC)
I wasn't being dismissive, I was being empathetic; I've felt the same thing (even though I hardly upload at all). The issue of time is real, it does take more time to upload as a new file than to upload as a new version, but the difference isn't that big (it's not like you have to recreate the changes from scratch). Nor is a revert in this situation as hard to fix as getting a file undeleted - just download the old version (if for some reason you don't have the upload any more), and upload it again under a new name. It is hassle, but only a small amount. Nor should any disrespect to the uploader be read here - it is about judging the community's needs, and when in doubt, stability of existing files is the decision criterion. There may be reusers eternally grateful for an improved version, there may be problems caused for others when overwriting a file in use. Uploading as a new file allows everyone to get what they want. Rd232 (talk) 10:36, 16 August 2012 (UTC)
Uhh, in the Migrant Mother case the original uploader and the reuploader are the same person. In your scenario, someone else reuploads over an original upload, we have no disagreement. I might consider my edit minor and initially reupload over the original file, but if the original uploader disagrees and reverts me I move it somewhere else. Your guideline supports this. But if I create a restoration history as I did in the Migrant Mother case, and someone like Prosfilaes, who has no restoration experience to speak of, reverts me and decides I have to move it somewhere else because of his/her assessment of what constitutes a minor or a major edit, I have a problem. This is the point I am trying to make, that in case of doubt we refer to the judgement of the original uploader. This is a simple matter of courtesy, but as has been amply demonstrated, courtesy towards the creator or uploader is in extremely short supply around here. And your guideline does nothing to change this. ~ trialsanderrors (talk) 11:55, 16 August 2012 (UTC)
While I sympathize with Trialsanderrors' views, I believe that most of the time this is not an issue. And where it is an issue, I simply do not agree that deference to the original uploader extends that far, and what Trialsanderrors issuggesting, in my opinion, extends beyond courtesy. In case of doubt, the path of least conflict is to upload the revision as a new file -- that solution does not prejudice anyone, nor does it involve undue extra work. Appointing the original uploader as an arbitrator is inviting problems. Having said that, in the event of dispute, notifying the uploader and asking for his/her thoughts is absolutely appropriate. --Skeezix1000 (talk) 12:45, 16 August 2012 (UTC)
If you create a restoration history, in the sense of uploading the unedited version and then soon after the edited version, that's covered by {{Unedited version}}, and if anyone wants the unedited version split out for some reason, they should do that themselves. Rd232 (talk) 13:12, 16 August 2012 (UTC)
You already have two editors disagreeing with you in this very thread. And as I said, I already spent too much stupid time arguing with people who were adamant that I should create a restoration history by uploading the files in the way they preferred, and this discussion makes it clear nothing will change even if this guideline will be implemented. But thanks for trying anyway. ~ trialsanderrors (talk) 15:58, 16 August 2012 (UTC)
I don't think anyone is disagreeing with the {{Unedited version}} part of the guideline; it wasn't clear to me at first that this was relevant here, and I'm sure the same is true of the others. Apply {{Unedited version}} to your uploads where relevant, and you should have fewer problems in future. Rd232 (talk) 16:41, 16 August 2012 (UTC)
Dude. It's a wiki. You don't own your uploads. I'm sorry if what the Wikimedia Foundation set up is not to your liking, but it's a community effort.--Prosfilaes (talk) 21:25, 16 August 2012 (UTC)
Tone aside (are you trying to make things worse in this discussion?), the "it's a wiki" philosophy you mention might be used to dismiss this entire guideline... certainly the fact that stability of files matters for Commons and its reusers is not negated by the fact that Commons is run on MediaWiki software. Rd232 (talk) 21:56, 16 August 2012 (UTC)
Stability matters. Consensus matters. Uploaders don't. I have trouble dealing with any editor who considers other editors "interloping". The only appropriate response to threats like "the alternative is that that I do not upload the original (or the edited version for that matter) at all if the only payoff is that I have to deal with people of your ilk." is "bye".--Prosfilaes (talk) 22:17, 16 August 2012 (UTC)
if all the uploaders get pissed off and leave, there will be both stability and consensus. Is that what you had in mind? And you may have trouble being empathetic, but that doesn't mean yours is "the only appropriate response". Rd232 (talk) 22:21, 16 August 2012 (UTC)
What empathy are you having for me being told that he will leave if he has to deal with people of my ilk? What empathy are you having for the users pushing mops, officially and unofficially, who just got described as "interlopers"? There are plenty of uploaders here who can deal with other people editing their images and disagreeing with them.--Prosfilaes (talk) 22:28, 16 August 2012 (UTC)
The things he said are clearly to be understood in a certain context of having been frustrated by actions of others. You should be able to cope with such general remarks (not related to a specific situation where a decision has to be made) without needing a shoulder to cry on (and I'm pretty sure you can cope). Rd232 (talk) 23:30, 16 August 2012 (UTC)
I did cope. I see his attitude as the problem; I don't see why I shouldn't point that out. I have no sympathy with someone who has argued over one minor issue with multiple people and complains about the amount of time he's spent arguing on the issue, instead of compromising.--Prosfilaes (talk) 23:42, 16 August 2012 (UTC)

The original uploader should not have the absolute right to determine if an overwrite is allowed or not. For instance, if the uploader uploads a new file that is completely different (eg replaces a b/w image with a colour one) that should be at a new location regardless of the uploader's opinion. That said, their views should be very much respected.

With regards to the situation here, if they upload a new version regardless of any suggestions on this page, the test to revert should not be "is the change major?", but "is the old version preferable?". A restored image is likely to be superior, unless the restoration job is flawed. If its a botched attempt, then you'll be ought to able to say why its flawed in a way the uploader is likely to agree with. "Reverting because you removed some dust spots" is pointlessly aggressive, "reverting because the levelling was too harsh and made the highlights clip" has a justification. The BRD cycle would then apply to resolve it. The general guidance should be phrased so that major alterations are discouraged, but if someone uploads a substantial tweak that is a clear improvement in every sense, is there any point to reverting? Seriously?--Nilfanion (talk) 23:16, 16 August 2012 (UTC)

Are you suggesting a change to the guideline text, or just making comments about how to interpret it? NB "removed some dust spots" is not a reason for reversion, but "removed some dust spots and it's a Featured Picture or and it's an institutional image where all restoration should be in a separate file" would be reasons. Rd232 (talk) 23:21, 16 August 2012 (UTC)
That comment about the interpretation really - its a guideline, not a policy, so its supposed to be flexible. It doesn't need to spell out "having an argument with the uploader for no good reason is silly". And agreed with the exceptions you mention.--Nilfanion (talk) 23:34, 16 August 2012 (UTC)

And the arguments just go on and on and on until there are no artists left to harass and argue with, and yet the arguments won't stop there, they'll just keep on going about how best to attract new artists to argue with and drive away yet again. Brilliant strategy.

The guideline is written to help people argue. It's not written to prevent arguments and thereby improve the project although that certainly was the intention. If I might make a suggestion before leaving you lot to bicker, give artists a set of tools to use. brushes paints and so on. Give them the ability to lockup images that they want to lockup. Let those who want to argue just copy the image and have their way with the copy while the artist can do more art. Some people like to argue endlessly and needlessly, it is what they wake up in the morning to do and that is what they base their day around. If you don't make tools to separate these people from the artists then that is what the artists will be forced to do until leaving and going somewhere else. Let the artists delete or overwrite what they want if it is their own work. Other people can copy it as they want along the way and argue as they wish. Has anyone mentioned rough drafts ? So the result of this discussion is, I end up getting an interface that is even harder to use than the impossibly difficult to use interface now ? oh joy. There are images used conversationally to say 'is this what you mean ?' uploading over them is an normal thing to do because of the time saving. In the last few days I've spent literally more than an hour waiting for an image to upload because as far as I can tell, commons was running a search for duplicates. This happens on just about every 3+ MB gif image, of which I have done a few. over-writing is occasionally a little faster. I don't care to be told to bring this up somewhere else, as I have in the past used answering machine talkpages to leave messages about improvements or whatever, everything dies in the ass through lack of interest, but rules to bicker over images gets plenty of attention I see. Very nice. It's like the whole someone decided that SVG was somehow the wave of the future, and now if someone needs something, and I am looking for component images to mix, I have to skim right on by svg's because the workaround is too complex. You can't download and mix same as png or jpg. Svg is SLOW to work with in inkscape. Does anyone know what an Internet meme is ? of course you do, it's those things that artists run off at a hundred miles an hour which make us all laugh, cry, angry, sad as art does, because the good artists are not spending their days arguing with people who wake up in the morning to set about asking a long list of artists to justify and explain their work ad nauseam because that is how they get validation. They don't spend their day wrestling with difficult interfaces they just move on. The internet meme article on english wikipedia could suck a golf ball through a garden hose. It has one image, and that image blows. It's not even funny. Stop producing monoculture amongst editors. Design the guidelines as a better set of tools, a wider variety of tools for a wider variety of situations. Stop driving people away. I have a non-sister project which uses commons files, and I don't want to use commons files because they can be overwritten so easily.

You're asking should editors be able to overwrite, delete, update, or lockup their images. The actual answer is yes. But you want to find a position for the lights witch halfway between on and off so that everyone is satisfied, where in the end it will just start a fire. Penyulap ☏ 02:17, 21 August 2012 (UTC)

That's rather a large collection of frustrations. Do you have a concrete suggestion for a change to be made to the guideline page? Rd232 (talk) 11:19, 21 August 2012 (UTC)

(heading added to aid navigation for section further down)

file attributes

Something to mirror the manner in which data files are stored anywhere else.
Generally, you can set permissions or attributes using a file manager or command line. This allows you to set attributes such as read only, edit, rename, and such. I know it seems a bit oversimplified, but it has been around on computers almost forever. The uploader can set flags or ask that they are set, that way people who come by later don't accidentally edit, rename or delete what is not meant to be edited, renamed or deleted, they can just download a copy of the file and then upload an edited version. Do you think it is worthwhile to include such a suggestion ? I recall that there was fuss over the 'stop online piracy act (SOPA)' and there was some story about an image of mist lifting cedars, I contacted the artist thinking it would be cool to have the image which was all over the news at the time on wiki, but wouldn't you know it, it was so controversial it could only be used for botanical purposes (don't know why I bother) anyhow, it got renamed and back again because there is no flag to set as read only, or any other flag at all. There is no space for up-loaders notes, the description just gets edited as well. Basically everything on the project is just plain random access, if it were looked upon as a computer system, it'd be time to re-install the operating system. I generally find it's hardly worth the time to type out obvious suggestions like this. They just get discussed to death and then killed off through lack of interest. Still I might as well point it out, but I can't see how it would go anywhere, can you ? Penyulap ☏ 04:39, 25 August 2012 (UTC)
I may be missing something, but this sounds like it's covered by the Commons:Protection policy. The exception would be allowing uploaders to choose the protection level of their files, which I don't see happening. Renaming files can already only be done by file movers and admins, not just anybody, and full protection against editing is rarely desirable. That leaves just upload protection, and the aim of this guideline is to avoid the need to use it much more widely (which, again, isn't likely to happen). Rd232 (talk) 20:27, 16 September 2012 (UTC)
Dumbass policy, that is what we got. Admins are supposed to know what the uploader intended through ESP ? The uploader can't set the attribute themselves, because they can't be trusted to be adults, they need to make applications in triplicate every time they take 30 seconds to make a cropped image or adjust colours, and some admin has to follow around because only they can be trusted to determine if the uploader knew what the uploader intended, rather than whatever the admin is assuming they intended through ESP.
"and full protection against editing is rarely desirable" of course, one attribute fits all files on your hard drive.
As far as I can see, Commons:Protection policy doesn't mention anywhere, even in passing, commons being used as a repository for outside sites. How is that supposed to loan credibility to the false claim that outside projects can make meaningful use of commons ? Someone sees an image on a non-sister wikipedia, clicks though to commons, and changes the image, the description, change a picture of the muppets to a porn image. Nobody can tell where and how an image is used on non-sister projects, even when it is used on sister projects they are all unstable. Nobody checks.
Even crappy windows operating systems had file protection attributes that could be set. Even windows 3.11 had it. Commons can't even manage that. People wake up in the morning, and go to work on files in a manner comparable in some ways to living viruses, deteriorating, deleting, damaging projects inside and out. The solution to all of this is like microsoft itself. You want to improve anything ? want to fix something ? spend 15 hours on hold and even if you get through and some other human being understands your concern, it's all filed away in oblivion and there is no improvement, ever. Penyulap ☏ 14:57, 18 September 2012 (UTC)
All right, I understand your concern a bit better. If you want files to (i) be protected much more widely or even by default and/or (ii) give uploaders the right to protect their uploads against changes by others, well, those are radical ideas which are way beyond the scope of this guideline (although if implemented obviously it would intersect with it). Why not start a thread at COM:VPR, and make a case? These ideas may be radical, but quite often today's radicalism is tomorrow's orthodoxy, so why not have it rather than just complain :) NB The comparison between a collaborative online media library and a personal computer operating system isn't really helpful, I'd leave that out. Rd232 (talk) 16:07, 18 September 2012 (UTC)
The analogue is a simple to understand approachable one, I don't care to improve on it, it's basically exactly the idea. But as for re-hashing the exact same discussion all over again so people can tire of it and it will go nowhere, this is as much the right place as not. Rehashing will do nothing. Penyulap ☏ 19:42, 18 September 2012 (UTC)
That's the spirit...! Er... Rd232 (talk) 19:51, 18 September 2012 (UTC)

Another case

Not sure whether the policy would allow what recently happened at File:Ramadhan Greetings Image.jpg (check the history of that page and User talk:Hindustanilanguage). If it doesn't, it should... AnonMoos (talk) 20:56, 21 August 2012 (UTC)

It's an error correction within 48 hours of first upload, so certainly reasonable in my book, even if it isn't entirely clear under what part of the guideline it fits ("minor improvement", perhaps, will be the norm for error correction, depending on the nature of the error and how long it's been there and how widely it's in use). Rd232 (talk) 23:42, 21 August 2012 (UTC)

I agree

  • Indeed guidance is welcome. I have seen a rare stamp image of low quality (forgery?) being replaced with a real stamp (Mauritius Post Office). It is clear that there should remain 2 distinct files in such a case. Could you treat this case as an example? It has a lot more significance than mere borders cropping!

Jacquesverlaeken (talk) 16:21, 18 August 2012 (UTC)

a suggestion

I think that a link to "Overwriting existing files" should be placed near the link "Upload a new version of this file", so that people are aware of what they can or cannot do before making a mistake. --Vermondo (talk) 12:57, 17 August 2012 (UTC)

I agree with Vermondo. I think you should write to our personal e-mail, as our General Director does, before deleting anything as you did with my pages were you eliminate figures and photos that are of my personal propierty. ==Cencinas
There's currently no way to do that. We could ask for one, I suppose, in addition to Bugzilla:39344 (which asks for an info message that can link to the guideline, when the link is clicked). Rd232 (talk) 16:49, 17 August 2012 (UTC)
I support this proposal. -- Justus Nussbaum (talk) 18:21, 22 August 2012 (UTC)

Intro phrase for summary

When someone first open this page, he tends to look at the summary first, skipping the intro in the first paragraph. I think a small explanation should be placed in the summary, to clarify what the icons mean. It could be as simple as "✓[OK]=Overwrite existing file; ✘=Upload as a new file.", but it also may be a small phrase (10-20 words). Razvan Socol (talk) 07:03, 19 August 2012 (UTC)

Indeed. The ✓[OK] and ✘ symbols are not universal. At least here, and I've understood also in Japan, the tick is used for errors. The colours help a little (if you can see them as red and green), but it is still confusing. --LPfi (talk) 19:25, 19 August 2012 (UTC)
Not universal? I had no idea... well if anyone has any suggestions for better symbols, I'm all ears. In the mean time, I've added a legend at the top of the page which I hope clarifies things enough. Rd232 (talk) 23:24, 19 August 2012 (UTC)
You are free to use other symbols if you are translating this page to Japanese. --TMg 13:55, 21 August 2012 (UTC)
Shouldn't the ✓[OK] and ✘ templates simply be localised in the same way as all other templates? --Stefan4 (talk) 13:59, 21 August 2012 (UTC)
{{Tick}} and {{Notok}} could certainly use different images for different languages - if anyone has any suggestions for replacements. Rd232 (talk) 23:36, 21 August 2012 (UTC)
would be good for {{Notok}} in Swedish and Finnish. The ok mark is visually similar to the %, but I do not know what search terms to use to find it on Commons or in Unicode. In Japan marujirushi and the X-mark seems to be the ones to use. --LPfi (talk) 13:14, 22 August 2012 (UTC)
OK, I've done that, using the red check and marujirushi (I can't find any "OK" symbol). I'm wondering whether to use {{Ok}} instead of {{Tick}} (giving the same symbol + the word "OK"). This might be slightly clearer. Rd232 (talk) 14:26, 22 August 2012 (UTC)
Some addition is needed, because now the symbols are identical, except for colour. Not good on a binary or grey-scale display. --LPfi (talk) 11:06, 23 August 2012 (UTC)
Right. What do sv/fi use for "OK"? Rd232 (talk) 11:24, 23 August 2012 (UTC)
OK is OK :-) --LPfi (talk) 14:35, 24 August 2012 (UTC)
sv/fi now have a green text "OK". Not quite pretty, but it works. Rd232 (talk) 23:37, 29 August 2012 (UTC)
Similar issues exist at Commons:Image casebook where and are used. --Walter Siegmund (talk) 00:02, 23 August 2012 (UTC)
replaced with the templates now. Rd232 (talk) 11:30, 23 August 2012 (UTC)

Using the colors green ✓[OK] and red for ✘ are also not helpful if one is color-blind. I am sure most people who are color-blind are well used to dealing with things such as this, but I would think accessibility would be a good idea? WayneyP (talk) 23:52, 26 August 2012 (UTC)

I think "accessibility" here means making sure colour is not the only way to distinguish the symbols. The shapes should also be clearly different - and they are. Rd232 (talk) 23:38, 29 August 2012 (UTC)
(＋)for support,(－)for oppose.Justincheng12345 (talk) 06:43, 27 August 2012 (UTC)

Problems

I am coming at this from the perspective of a art historian.

I have problems with some of the exceptions listed here.

NOTE: The following are referred to as "minor improvements", not requiring that the original be kept:

As a general rule, use the link "Upload a new version of this file" only for relatively minor improvements. Examples include:
*color correction
*removal of a watermark
*rotation of images of that are not upright
*replacement with higher resolution versions of the same file
*minor cropping

The problem is that many editors do not recognise that these types of edits may be invasive or inappropriate.

  1. Colour correction. I have had it argued that automatic digitised colours corrections get "the right colour. They don't. Automatic colour corrections can be very bad indeed. Colour corrections to any work of art is a very delicate process and requires experience, a knowledge of the particular art media and ideally, access to the original artwork.
  2. Rotation of images that are not upright. If this means turning an image through 90 degrees so that buildings are vertical and not lying down, then it is no problem. But if this means straightening and cropping, or counteracting camera distortion, then in neither case is the adjustment "minor". Counteracting camera distortion can totally wreck an image when done by the average editor who doesn't really understand perspective. There is a ghastly example on Wikimedia Commons where someone has "fixed" the Abbey of Saint-Etienne, Caen, so that it is no longer a building with very tall towers and semi-circular arches. It now has short squat towers and arches of the sort known as "depressed". When someone does this sort of stuff and deletes the original, and I suddenly discover the mess-up in an article where the original has been used, I get very cross!
  3. Replacement of higher resolution versions of the same file. People sometimes take this to mean "a version of the same picture" rather than "same file". Once again, when dealing with artworks, one may get a high resolution image that is so dark that the details cannot be seen in low res, and other such problems.
  4. Minor cropping. Cropping of borders from prints (I mean etchings, engravings, book illustrations, woodcuts, mounted photos etc) is simply not on. Cropping the borders off anything of this nature doesn't constitute a minor correction. In general, it shouldn't be done at all. However, there is a case for cropping in situations where the print is being used out of the context of "artwork" eg. cropping a detail from a larger print to indicate what a particular building looked like in a previous century, or cropping the face from a group photo to illustrate what a person looked like. Where pictures have been cropped for use of this sort, then the original with border ought always be retained.
  5. Minor cropping because the edge of an artwork is damaged also ought not happen, because the composition is altered by the crop. The exception to this is in the case of an oil painting that has been designed to be framed, but photographed with its frame removed. There is generally a clear line of abrasion right around the picture, but this ought not be confuse with the other line of abrasion that occurs on canvases where the wooden stretch on which the picture is mounted may may a ridge about 3 cm from the edge of the picture. The picture should never be cropped at that point.

My view is that any colour correction, rotation or cropping ought to maintain the original file, in the case of every artwork, architectural photo, stained glass window, art photo or art print.

Colourwise, it is artworks that are most often badly handled.

Rotation and straightenwise: it is architecture that is badly handled

Cropwise: the biggest problem is with prints.

Amandajm (talk) 13:02, 23 August 2012 (UTC)

Fair enough. The easiest way to integrate these concerns would be with a big expansion of the Examples section. You could also propose an amendment to the guideline, but we need to avoid making it too prescriptive, and allow people to use their judgement. Examples help guide judgement without restricting it with very detailed rules, so I lean to that. Rd232 (talk) 13:41, 23 August 2012 (UTC)
I think we also agree that the original should not be deleted. If overwritten with a misguided "improvement", this can be reverted, the original restored and the "improved" image uploaded under a new name if somebody insists it was indeed an improvement. As only administrators can delete files (and should delete them only for good reasons, checking for derived works) the problem should be quite easily handled, but avoiding bad "improvements" is of course a good thing. --LPfi (talk) 14:44, 24 August 2012 (UTC)
I agree with you. Whatever alterations are minor, the original should not be deleted. The vision of an image is never the same regardless of the beholder! PierreB (talk) 13:21, 25 August 2012 (UTC)


Historical versions required by some projects

The Wikinews perspective

  • Commons repeatedly uploading new version of images — such as the spread of Avian Flu — have proven problematic for Wikinews in the past.
If an image is in-use on a Wikinews article, then it is generally required to be - per our policies - a snapshot of what was known at that time. Uploading a revised version of the image renders a historical document on Wikinews factually inaccurate in such cases. --Brian McNeil / talk 12:30, 25 August 2012 (UTC)
If Wikinews is using an image they themselves will have to be sure they are not using an image that is prone to updating, if that is what they want. It means that they will have to choose an image with a filename and description that makes it plausible that it will not be updated. For instance, File:Sunspot butterfly graph.gif is by its name and description not a stable image, whereas File:Borders of Poland and Belarus before August 1945.png is. If they need a snapshot of an image that is likely to be updated, they will simply have to make a copy with an appropriate filename and description. I asked here before to include a line in the upload procedure that adds the purpose of an uploaded file to the description section, so it would be clear to anyone wether it is preferable to preserve it, or whether it is updateable. It would prevent a lot of the uploads that this proposed guideline tries to harnass. "Upload a new version of this file" is a Commons feature, not a nuisance. Jan Arkesteijn (talk) 14:55, 25 August 2012 (UTC)
While Jan may be right about file naming, it is not a helpful comment, as it is not addressing the issue that Brian broaches. Files that are of a time and a place, or relate to static data, and where the filename does not reflect that are prime targets for {{rename}}, and that should suit both parties.  — billinghurst sDrewth 10:26, 26 August 2012 (UTC) BUT
Anyone who started using images from Commons was or should have been aware of the (im)possibilities of this service. If someone needs a file in a specific state, which Commons even with this guideline is not able to garantuee, should, as a last resort, make this file available locally. Jan Arkesteijn (talk) 10:57, 26 August 2012 (UTC)
Exactly. Precisely the point. Commons makes the claim that it can act as a repository. It is a false claim. The claim is the bait to upload images that everyone can start an argument over. For an actual repository, try elsewhere, for an epic fail at stability, this is the place. Penyulap ☏ 08:37, 17 September 2012 (UTC)

In the case of avian flu, a generic file name should be used for the current cases of the flu, and a date specific file name should be used for the spread on that date. Wikinews can choose whichever to use. It is up to whoever thinks it might be useful to determine how many dated versions to create. Now that newspapers are on the web and not just on your news stand, some articles and images are chosen that are auto-updated, so that when they are read years later the current image reflects the situation years after the original article was written. I do not have an example in mind, but have seen it done this way. Delphi234 (talk) 00:44, 27 August 2012 (UTC)

Even error corrections might not be wanted. The image in the article should probably reflect what was known or thought to be correct at that time, not the situation at that time as known later. If we want wikinews always to copy the image to a new name and mark it with a template, then this should be discussed with wikinews. We also should adjust the file naming and file renaming policies to reflect that the name will influence how the file is treated. This would be quite a big change in policy.
Maps and diagrams are usually meant to either reflect a certain point in time or to be updated, which means adding either to the name is obviously useful. The same is not the case with many other files. Photographies nearly always represent the time when they were taken with no need of updating, at least by current policy. With the current wording in the new guideline "Somewherestan flag outside the Parliament building.jpg" might however be replaced when the flag is changed. This is good for some uses, but very bad for others.
--LPfi (talk) 07:40, 29 August 2012 (UTC)
If images are needed that are updated frequently, one can define "Flu current situation.jpg" and redirect it to the latest version available. --Foroa (talk) 08:25, 29 August 2012 (UTC)
Actually the filename of "Flu current situation.jpg" is a horrible choice as the semantics implies that it was the current situation when it was created and that it is not expected to be updated. A better choice is "Flu situation.jpg" with the implication that since no date is indicated it might be updated. While files with a date in the file name are certain to not be updated with current data (most of the time), generic file names are not necessarily updateable, but are more commonly updateable. It is necessary to use best judgement, there is no rule that can be applied. If you look at all of the rules, they are all riddled with exceptions. For example, the current data section starts out by saying these are files that are updated, but in most cases they should not be updated. Is that really something that is going to be easy to understand? When I read it I get confused whether I am in the section of files that should not be updated or in the section where files should be updated. As an aside, I want to point out that using edit summaries to explain talk comments is less than useless. It is a helpful comment that "automatic updatebility if no date indicated in file name would be big change in policy" but putting that in the edit summary makes it less likely to be seen. In some cases the lack of a date does indicate automatic updatability, in most cases it does not. There are no rules that can specify which is which. Delphi234 (talk) 15:43, 29 August 2012 (UTC)
A more logically correct file name for a transfer file name would be "Flu situation redirect to the currently available flu data filename.jpg" Delphi234 (talk) 15:57, 29 August 2012 (UTC)
In the section above I suggest #file attributes which would fix that problem, especially if you add numbers representing the date into the filename, however, as I stated at the time that I suggested the obvious good solution which follows the norm across the world of computing, the suggestion goes nowhere. Good ideas, like good art, is unwelcome on wikipedia. There is the suggestion that files can be stored here and used on other non-sister projects, what a stupid idea in my experience, I drew a free image of the chinese space station, some gap filler till I had time to do a full 3D rendered animation like you see on the news, but one person took a dislike to it. Others liked it, there was a discussion and consensus, the image itself I released into the public domain with a OTRS ticket. Didn't stop the person rewriting the description as soon as my back was turned saying it was inaccurate. This is an image described originally as an artists impression. An artists impression is much the same as an opinion, it cannot be inaccurate unless someone has messed with the image I drew and changed it so it no longer resembles what I drew. Nope, one person doesn't give a toss, and so what point hosting mediawiki site's images on commons ? that would be just plain stupid. Every 5 minutes someone is tinkering with the description or just deleting the image itself 'out of scope' or some crap, host images here for use elsewhere ? How ? you can't even tell if they are in use elsewhere. Give the images templates and you give vandals a helping hand wrecking other sites.
File attributes, read-only, it solves these problems, good for the news, good for lots of things. That is why there are no comments about it for three weeks or so. Because good ideas, like good art, has no place on commons. How do people work out what to delete ? oh that is simple, look for the good stuff, that must be commercial. It's the undercurrent that wrecks the place, along with the shit and politics and apathy and everything else that prevents wikipedia being anything that it was or is proposed to be. Even the simplest test images don't stay still, or are deleted, so why bother making or uploading anything better ? am I a fucking idiot ? by the time you wrestle with the complex forms and licenses and OTRS delays and uploading a 3MB file onto commons takes literally more than an hour for god knows why, you could have done it all 6 times somewhere else. There are 100 better quality repositories out there, and just upload it onto your own wiki. That's what I did, simple. There are images I made and I have a fucking good idea that I won't come back in three weeks to find them deleted two weeks ago and holes in the articles if I write and draw. Put half a dozen commercial grade artworks on popular topics onto commons ? why ? just so I can watch them blink on and off as the are deleted and undeleted every other week ? stuff that.
Stability will never happen. People love the stupid game of cat and mouse too much. The people who don't spend every day on commons babysitting their images are better off putting them somewhere else. One policy fits all images ? not on planet reality.
The day that all arguments are rendered moot by a better system is the day you find yourself on a different website altogether. Penyulap ☏ 17:57, 16 September 2012 (UTC)
I can't see in Special:DeletedContributions/Penyulap what prompted this outburst (nor any obviously wrong deletions). If you actually want a useful response, as opposed to getting your complaints off your chest, provide specifics. (Though most of what you've said above and elsewhere on this page is not really of direct relevance to this guideline; you might be better off reposting at COM:VP.) Rd232 (talk) 20:36, 16 September 2012 (UTC)
I can't see in Special:DeletedContributions/Penyulap either, I can look out my window and see the sky however, what does this have to do with anything ? I won't try mentioning the chinese space station, I've tried that with my last comment and apparently it failed to translate. VP? hey, I wonder if they can tell me to come and post on this page instead, there is an idea, I .
Which specific do you want ? the exact examples which I've outlined specifically or the specific solution that I've specifically suggested ? The best way to suggest improvements on wikipedia is to first be happy with the way that things are, and see that nothing needs improvement. It's not the spoon that bends, because there is no spoon. If there was any problem or frustration, then that is exactly what we do not want to know, agreed ? First look into yourself and see that the thing that needs changing is not what is broken, but the idea that it is broken is what needs to change. Penyulap ☏ 04:43, 17 September 2012 (UTC)
You can't see the page Special:DeletedContributions/Penyulap because you're not an admin; I am and it shows me the list of your deleted contributions. I can't tell from that list what cases you're talking about above, so I asked you to tell me the specific files / DRs that upset you, to help me understand. PS as I pointed out up the page (maybe you missed my reply) your "file attributes" idea appears to be essentially what MediaWiki calls "file protection" - see COM:PROTECT. Rd232 (talk) 11:00, 17 September 2012 (UTC)
The page explains to people why it doesn't work for them. The description of the Chinese space station is what was changed. It wasn't deleted like this one was, so it doesn't flash on and off wherever it is used, just when it is viewed from somewhere else, it was showing the wrong description. You just look through my uploads and it is the thing that looks like a space station out in space and it has a Chinese file name because it's Chinese. There is the main image and two crops, I can't recall which one it was, but it was one of them, the one on display. Someone decided it was not an 'accurate' artists impression, wtf do they think my impression was ? I think I should know what I think. But who cares ? attributes are pointless because where is the fun in having something you can't mutilate ? the only thing it would do is give the impression to artists that they can use commons as a repository. I wonder if this shit happens on flicker. Penyulap ☏ 12:14, 18 September 2012 (UTC)
Flickr does not intend to be educational (AFAIK) or collaborative in the sense that Commons is. Now with a bit of detective work (you didn't make this easy...) I guess you're talking about File:中國空間站二.PNG, where someone added a "contains severe inaccuracies" remark to the description, which you removed. I do not see any explanation of the remark, or discussion of it on the file talkpage or your or the tagger's user talk page. I guess if the tagger couldn't be bothered to explain it or to contest the removal, the removal is fine... But fundamentally, if you draw X and expect the resulting drawing to be educationally useful (COM:SCOPE), you must be prepared to discuss the accuracy of the drawing. This may be annoying in practice, but it should not be upsetting in principle. In any case, this example has absolutely nothing to do with this guideline, since it does not involve overwriting a file. Rd232 (talk) 12:31, 18 September 2012 (UTC)
The image of the Chinese space station was discussed here, and as you can see, there are people who like it, and only a lone dissenter. One is all it takes.
The topic is overwriting files. If attributes doesn't address that, nothing does. Problem here is instead of orthogonally moving the problem in hand and creating a new set of problems and paperwork on top of it, attributes solves about 10 different problems altogether. The idea doesn't belong here because it is too large an improvement.
In general, much of wikipedia reminds me of the way dogs fill up with water and patrol the neighbourhood. Deleting files has nothing to do with EV, it has to do with whatever is in front of the person looking, the tree trunk is here, so it will do. The bush is here, so it will do, whatever this thing is here, it will do. Thought never comes into it. If it is in front of the person, it is as good as anything else to propose for deletion or just maul in some way. Standard operating procedure is to delete just to provoke discussion. It's not the files demanding validation here, and if nobody is around to stop the deletion by pointing out the bleeding obvious because they are busy creating great content somewhere else or busy in RL then it gets deleted. It disappears from this site, as well as any outside wiki stupid enough to put images here.
I've been absorbing a S*Load of skills in graphics and video creation software, in part because of my previous interest in space stations and the fact that China and Russia will never release their images and animations onto free licenses. There are never going to be NASA crew sent to the Chinese space station with a camera, so there is only 'fair use' theft of images and that's all. The Polyus orbital interceptor / destroyer that was launched has no images on commons because it's all copyright. That thing is amazing, it's like 8 times heavier than any of the laboratories on the ISS, plus, it could eject targets and blast them with a 1 megawatt carbon dioxide laser. That is cool shit right there. Where are the pics ?
So not even one image, simple as they come, of the Chinese space station can last on here, and what, I'm going to have my site link through to it ? what would possess me to do such a thing ? as for drawing any more, as for going to the trouble of doing what I can soon do, which is draw the same animations that you see on the news, except draw them a whole lot better, wtf would I ? as soon as my back is turned the effort is for nothing. Do I look like a moron to you ? I should paint oil on canvas and store it at the bus interchange. Now I mostly make art by request and for userspace, for people who like it, at least that way it will last as long as they do, and I can get on with something else. Like you said yourself "if the tagger couldn't be bothered to explain it or to contest the removal, the removal is fine" Just set yourself a target of deleting 100,000 random files from commons, and you'll have the greatest success where people have their back turned or have left already, EV means nothing.
I recall reading someone notable saying if a photographer or artist is not notable then their work is not welcome. It was a truly foot in mouth moment, because most contributors are not notable, most of the featured content, and the artists in the graphics lab, it's like, why bother, we can all go home. Commons sucks, and it's not going to get any better because nobody gives a **.
Attributes is a simple thing, filename conflict is trivial, just prefix files intended to be read only with the upload datestamp as part of the filename. Like you say, it's beyond the scope of discussion, because we're not discussing any improvement here, just arranging the deckchairs for some equivalent of MOS nazis or something. Vandals and deterioration will still proceed anywhere it's not seen, plus, it's another burden and discouragement for artists in itself. One more bs rule to deal with, on top of a heap of crippling nonsense as it is. Whatever. Penyulap ☏ 19:27, 18 September 2012 (UTC)

Wikisource perspective

Wikisource works on an edition of a work, and that detail is usually captured in the {{book}} template, and not specifically in the filename, and some filenames would be horrendous if we needed to capture title, edition, authors, and other publication detail to make the title that specific. Overwriting a work at Commons that is used at Wikisource is something that we only do rarely and then with our eyes wide open, and with a mindful approach to a new scanned version of work. Books even by the same title can be different; different languages, translators, missing scanned pages, different number of lead in pages, (blah blah blah). So the Wikisource's opinion is that the works used at a WS should not be overwritten unless it is fully in consultation with the Wikisource community and/or whomever uploaded the original work, it becomes a nightmare to resolve if done in isolation just at Commons.  — billinghurst sDrewth 10:26, 26 August 2012 (UTC)

You might already have it, but I'd suggest a large, brightly colored template warning people not to upload new versions. Sven Manguard Wha? 21:53, 26 August 2012 (UTC)

Tools

Projects wanting stable versions is a general idea covered by the guideline. Projects wanting static or historical versions is different; that need should be signalled on Commons by the project using the file. We can make a new template {{Please-do-not-overwrite-historical-version}}, which can be added to a file description page. Alternatively, we can pursue Commons:VPR#Transcluding_old_file_versions for all projects: it is technically possible to transclude old versions of Commons files on other projects, so that later updates to the file don't affect that page. It's just a MediaWiki setting which for some reason is not turned on for Wikimedia projects. Finally, it would probably be a good idea to have a bot identify files in use on projects that need historical versions, either to apply the new template or (if we get the MediaWiki setting switched) to change the transclusion to a transclusion of the specific file version. Rd232 (talk) 23:11, 29 August 2012 (UTC)

What constitutes a historical file that shouldn't be overwritten? Obviously File:COLORADO-PAGOSA SPRINGS - NARA - 544921.tif does, but what about its jpg derivative? The latter could easily be improved by cropping the old slide border and a bit of colour level adjustment to remove the red cast; if done, should that be a third file, or is that overkill? - MPF (talk) 13:10, 30 August 2012 (UTC)
What is wrong with using {{Please-do-not-overwrite-original-files}}? Creating extra templates does not seem warranted. Delphi234 (talk) 04:43, 31 August 2012 (UTC)
My preference is to have at it with the jpg derivative - it is a lossy compression anyway, so whatever was done is not really needed in creating a better one in the future, and keeping a dozen jpg's is not very useful. If you make substantial changes like cropping or dramatically changing the size, that is different. Delphi234 (talk) 04:51, 31 August 2012 (UTC)
You're talking about the "original files" case here, for files coming from institutions where we want to preserve the original. This logic doesn't apply to any derivative files - the normal rules apply there. (Incidentally, that improved jpeg should probably be a tiff itself, to avoid generational loss in editing: see Commons:Lossy and lossless compression. If a jpeg version is required for some reason, that should be a third file.) Rd232 (talk) 10:08, 31 August 2012 (UTC)
I've created {{Please-do-not-overwrite-permanent-version}}. The difference between that and {{Please-do-not-overwrite-original-files}} is obvious from the templates. "permanent" version is hopefully clearer than "historical." If this seems helpful for the Wikinews/Wikisource cases, someone please add it to the guideline. Rd232 (talk) 10:04, 31 August 2012 (UTC)
Now added. Rd232 (talk) 10:28, 8 September 2012 (UTC)

advertising this RFC elsewhere

In my opinion, because all the WMF projects use the Commons' files, this RFC should be advertised in each project's Village Pump or equivalent. msh210@enwikt 19:40, 29 August 2012 (UTC)

I have no objection. It's a good opportunity to raise awareness of these issues more widely. Is it worth doing a m:CentralNotice, rather than having lots of postings on individual projects? Rd232 (talk) 22:57, 29 August 2012 (UTC)

Redirects

Is this just an idea or does anyone know of examples where this is done? If so, can we use an actual example, instead of showing three redlinks as the example? By the way, using "redirect" in the redirect file name is probably better than (current), and definitely better than using "current". Delphi234 (talk) 19:46, 29 August 2012 (UTC)

Real examples would be better, yes. I don't know of any myself, but I think I have seen some in the past. Rd232 (talk) 23:40, 29 August 2012 (UTC)

Statement by Incnis Mrsi

I know, the new rule will be approved without amendments by a majority vote, but I have to say this anyway. Many users of this majority thinks about Commons as an ideal world, and expect that uploaders are responsive. With the only trouble that they frequently violate the copyright, certainly, in their best faith. This perception is not correct, this world is far from being an ideal one. There is a lot of crap on Wikimedia Commons. Many uploaders dump various waste here, they do not care about how other people will use it, and would it be useful for someone but this uploader himself. Several months ago, I made the "worst images" gallery, only to be obstructed by the community. Some users argued that an image is either in scope or out of scope. Now, in the Category:Erroneous geometry you may see images which are in scope, but which are educationally harmful. One of such images is currently in use. And it is only geometry where I can apply my personal expertise. How much crap do exist in other domains? In Wikipedia, any article, which is either a duplicate or a patented crap, is eliminated in few days. Commons does not have, and never had such a policy. From now on, Commons will even disallow to fix (i.e. to reupload or redirect) a crap. Uploading duplicates, degraded versions, images easily replaceable with HTML (such as a table or a collage, possibly of several images), and an outright waste, is no restricted here. Which consequences will this have? After several years, some categories ceased to be navigable and the average Commons' content will gradually become similar to a landfill's content. To avoid this, the government should exist, which will discretionally implement aforementioned measures to abate these heaps of waste. Incnis Mrsi (talk) 21:21, 7 September 2012 (UTC)

The problem of proliferation of content to a point where it becomes harder and harder (i) for contributors to manage, and (ii) for users to navigate and find useful things, is very real. But the current guideline proposal formalises practice which exists for very good reasons, and even if that practice were radically changed it wouldn't make much impact on the proliferation of content problem. To pick up your comparison with Wikipedia: Wikipedia has a basic idea of only having one article per topic (although there can be many related articles on different aspects of the topic). By contrast, Commons doesn't have that: there can be very many images of the same or very similar subjects. That's an intrinsic difference between an encyclopedia and a media library.
To give a more helpful response: yes, we can talk about the proliferation issue, it's been in the back of my mind to start an RFC about it. Rd232 (talk) 21:32, 7 September 2012 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Proposal

Change title to "Commons:Changes to existing files", because that is what this is about - when to create a new file and when to upload a new version. It is not about "Overwriting existing files". Moving it will automatically create a redirect from "Commons:Overwriting existing files". Delphi234 (talk) 03:15, 8 September 2012 (UTC)

Overwriting and changing are functionally the same thing. Sven Manguard Wha? 04:55, 8 September 2012 (UTC)
I don't see the need. The "overwrite" terminology and COM:OVERWRITE shortcut for it are quite familiar to many people, so I wouldn't rename away from that without good reason. Rd232 (talk) 10:27, 8 September 2012 (UTC)
Changes seems to ignore the common case of replacing the file with a whole new one.--Prosfilaes (talk) 21:23, 8 September 2012 (UTC)
I oppose the proposal. To create new (derivative as well as non-derivative) files and upload them is (itself) uncontroversial and is not the matter of this guideline. This guideline is focused specific on the problem of overwriting existing files. --ŠJů (talk) 23:59, 5 January 2013 (UTC)
I agree with the spirit of this proposal, but in lieu of the above concerns, perhaps "Updating existing files" is the best fit for a new name. This would cover all conceivable cases that I can think of, and remains clear (and significantly more accurate than "overwriting"). The concern about moving away from often-used shortcuts is legitimate, but in this case I believe the change is worthwhile: I myself (a new editor) was confused and concerned by the "overwriting" terminology, fearful that I would be eradicating an earlier contributor's work if I "overwrote" a Commons file. FormAllTheHides (talk) 02:36, 30 March 2017 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Overwriting_existing_files/Archive_1&oldid=467643981"