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

peter green plugwash at P10Link.net
Tue Feb 20 01:27:20 UTC 2007



> -----Original Message-----
> From: commons-l-bounces at lists.wikimedia.org
> [mailto:commons-l-bounces at lists.wikimedia.org]On Behalf Of Brianna
> Laugher
> Sent: 20 February 2007 01:07
> To: Wikimedia Commons Discussion List
> Subject: Re: [Commons-l] [Foundation-l] Commons request for input:
> policy onautomatic image replacement
> 
> 
> On 20/02/07, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> > On 2/19/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> > [snip]
> > > 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.
> >
> > I don't think we should make it a policy to always keep extra images,
> > we should do so only when there is an honest and reasonable
> > disagreement over which image is better. Many times there is no
> > disagreement, and we shouldn't keep around many useless near
> > duplicates just because.
> >
> > So, for example, if a version is unused on other projects there should
> > be no problem.
> 
> Well in those cases we can virtually do what we like, because no one
> will notice. ;)
> However I suspect we still have quite an army of hardworking "SVG
> gnomes" who spend some time re-linking PNGs as SVGs. Then, when an
> admin comes to *look* at the image, it appears that is not used
> (virtually, was never used). I don't know what to do about these
> gnomes...
its a pretty serious issue with mediawiki, categories suffer from the same problem.

i'm not going to go looking for bug reports right now but i bet its already been reported.

the problem is we only track history for page text and file content. While all other history can in theory be recovered from this in practice such searches would be impractically slow but this is a big change that would need to be done by the core devs and they are busy firefighting growth issues afaict.

one thing you can do is check where the svg is used and look for recent edit warring over the issue but thats a lot of work.

personally i think such svg gnomes should be blocked on sight but thats a descision for individual projects to make.





More information about the Commons-l mailing list