[Foundation-l] Possible solution for image filter

Milos Rancic millosh at gmail.com
Wed Sep 21 13:06:31 UTC 2011


On Wed, Sep 21, 2011 at 11:10, WereSpielChequers
<werespielchequers at gmail.com> wrote:
> Forking and creating "safe" versions of all our wikis has the same
> disadvantage of any other fork, the wisdom of crowds is dissipated if the
> crowd is ever further divided. In that sense this would be as much a mistake
> as it was to spin Outreach, Strategy and Ten off as separate wikis rather
> than projects on meta. Better to encompass both "safe" and existing wikis
> within the same wiki by making the image filter an opt in user choice, that
> way you achieve all the advantages of "safe" and unsafe wikis without any of
> the overheads. I think you'll find that was always the intention, I don't
> recall anyone arguing for it to be compulsory for everyone to opt in to the
> filter and pick at least one thing they object to.
>
> Commons is a different matter, and I can understand the concern there that
> this might lead to arguments as to the categorisation of particular
> articles. Personally I think that it would be progress to replace arguments
> as to whether an image is within scope with arguments about the category.
> But this does depend on the way in which the filter is implemented; If we
> implement a filter which offers 8-15 broad choices to those who opt in to
> it, then  those filters probably don't currently exist on Commons, so by
> implication we as a community are vetting all of commons to see what fits
> into those filters. Such a system also conflicts with other things we are
> doing, in particular the GLAM collaborations and the large releases of
> images that we are getting from various institutions. But if we go down the
> more flexible personal image filter route then there is far less reason to
> fork Commons as it makes no difference on Commons whether an image is
> blocked by one reader on their personal preferences or by one million. There
> would still be the issue that not everything is categorised, but if we
> release this in beta test and don't over promise its functionality that
> should not be a problem - we just need to make clear that it is currently x%
> efficient and will improve as people identify stuff they don't want to see
> again, and categories where they want to first check the caption or alt text
> in order to decide whether to view them.

You didn't understand me well. It's not about fork(s), it's about
wrappers, shells around the existing projects.

* en.safe.wikipedia.org/wiki/<whatever> would point to
en.wikipedia.org/wiki/<whatever>
* When you click on "edit" from en.safe, you would get the same text
as on en.wp.
* When you click on "save" from en.safe, you would save the text on
en.wp, as well.
* The only difference is that images in wikitext won't be shown like
[[File:<something sensible>.jpg]], but as
[[File:fd37dae713526ee2da82f5a6cf6431de.jpg]].
* safe.wikimedia.org won't be Commons fork, but area for image
categorization to those who want to work on it. It is not the job of
Commons community to work on personal wishes of American
right-wingers.

(Note: "safe" is not good option for name, as it has four characters
and it could be used for language editions of Wikipedia; maybe
safe.en.wikipedia.org could be better option.)



More information about the foundation-l mailing list