[Foundation-l] Commons request for input: policy on automatic image replacement

[Brianna Laugher]

Hello,

(If your project doesn't have a CommonsTicker... GET ONE...
http://meta.wikimedia.org/wiki/User:Duesentrieb/CommonsTicker
and if nobody maintains it... well don't complain you were never informed :P )

CommonsDelinker is a Wikimedia-wide bot designed to remove image
redlinks from pages after an image has been deleted at Commons.
http://meta.wikimedia.org/wiki/User:CommonsDelinker

At the moment it is in the "testing" stage of image "relinking" --
replacing one image with another. I want to get some input from
communities about under what circumstances it would be acceptable for
Commons to use the bot for "relinking".

There are several reasons why replacing images might be desired:

1. Avoid conflicts with local image of the same name (bug 889, 2717)
[although usually this would be done at the local wiki rather than
Commons, but if the Commons image is poorly named, it can be
appropriate]
2. Rename images: as redirects don't work, the only option to upload
under the new name (bug 709, 4470)
3. Consolidate use of duplicate images at just one of them
4. Replace an image with a distinct, "improved" version

I guess (hope) 1 and 2 are not controversial. So I want to talk a bit
about 3 and 4.

Regarding 3: some people feel that there is no need to consolidate
duplicate images together. While it is true that there is no argument
to do this for "disk space reasons", consider it like a 'fork' of the
image. We don't allow forks of articles. One reason, for sure, has to
do with NPOV, but another reason is just about efficiency and the
natural human tendency to sort, collate, collect and organise. It
makes sense to have all the info about one thing in one place, whether
that is a topic (article) or an image.

Now regarding 4. This is the first point where the image being
replaced is not a true duplicate to the original. The most contentious
point has been where images are converted from raster (GIF, JPG, PNG)
to vector (SVG) format.
I don't want to hash out the details of a PNG vs SVG debate here. Some
PNGs are superior to SVGs, some SVGs are superior to PNGs. I want to
establish: what process should take place before a bot replacement
like this is acceptable?

Because it's a bot, I want Commons to have really clear guidelines
about when it is OK to use it, to avoid disrupting local projects.

Currently, such images are tagged with {{superseded}} and listed at
http://commons.wikimedia.org/wiki/Commons:Deletion_requests/Superseded
. This page is quite backlogged (nearly 5 months, over 5000 items in
[[category:superseded]]) and almost no-one works on it (since our
copyvios are also backlogged, and they are more urgent, this is OK,
IMO).

Note: we have {{superseded}}, which usually means the old one will be
nominated for deletion, and we also have {{vector version available}},
which merely advertises the existence of a vector file and does not
imply the old one should be deleted.

So basically my question is, assuming someone putting a {{superseded}}
tag on an image appears on your local CommonsTicker, how long is it
acceptable to wait before we replace such images? A week, a fortnight,
a month?
What should consensus look like in such discussions? Since we don't
have to delete things for copyright reasons, is *one* person objecting
enough to keep the image? What if that person is the uploader? What
reasons should ensure an image gets kept?

Here are some main ones I know of:
* Art. IMO no art "near-duplicates" should be deleted unless they are
TRUE duplicates (eg by hash). Colour differences are too subjective to
rule which one is the most accurate, so best idea is to keep them all
and let local projects decide which to use.
* Small size PNGs used as icons - may be hand-optimised for rendering
in IE, which SVGs will still suffer from (as they thumbnail to PNG but
without special treatment).
* Errors in SVG rendering (there are many in bugzilla)
* PNGs as source files - should be kept for historical record (luckily
we can undelete now, this is not such a big deal, but still something
to keep in mind)

So, please take this as an opportunity to describe the most open and
accessible way Commons can work with your project, and how you would
like to see it operate to best benefit your project in this regard.

cheers,
Brianna
user:pfctdayelise