[Foundation-l] The status of smaller languages on the Wikimedia Commons

Gerard Meijssen gerard.meijssen at gmail.com
Fri May 5 18:52:52 UTC 2006


Daniel Arnold wrote:
> Am Freitag, 05. Mai 2006 11:30 schrieb Gerard Meijssen:
>   
>> Wrong. InstantCommons has everything to do with the WM Foundation.
>> InstantCommons would have been coded by now if this was not the case.
>>     
>
> InstantCommons is a nice idea but without a notification framework that 
> *automatically* notifies other projects about things that need their 
> attention like duplicate files, files missing required info and all kinds of
> deletion requests it simply would increase our current problems by a order of 
> magnitude and thus would make Commons unmaintainable.
>   
It does not. At this moment there is nothing stopping people from taking 
content from Commons. People do. We are not responsible for this, as it 
is. The best we can do is what we do. Mind you InstantCommons is NOT to 
be used for Wikimedia projects. From a performance point of view, 
currently many installations use the pictures of Commons on a real time 
basis. This has an impact on our responsiveness.

The consequence of what you are saying is that our pictures are not Free 
to use. The fact is that no matter how diligent and intelligent we 
maintain Commons we will never get to the situation where all material 
is certified as being completely and correctly. This means that either 
Commons is Free for people to use or it is not. With InstantCommons Meta 
data will be available about these pictures on the remote Wikis. 
Consequently the situation will be much better to find the material that 
needs deletion and that is also elsewhere. Remember, Google is our 
friend :) We can even build in some functionality that helps the remote 
administrator to check Commons for issues. This however is something 
that they have to do. It is not our responsibility.
> Duesentrieb (http://commons.wikimedia.org/wiki/User:Duesentrieb) is currently 
> writing an automated notification framework called CommonsTicker that would 
> run on the tool server and would work as follows:
>
> A database cronjob at the toolserver looks for new files that need the above 
> described attention. The new files will be send through CheckUsage on the 
> same server and this will return a usage list of these images of every local 
> project. In the end a pybot will write in every local project a at a 
> dedicated page a daily compiled list of files that get used by them and that 
> need their attention (like unlinking images and thus reducing image "holes" 
> in articles, alerting people on deletion debates in Commons and so forth).
>
> Of course this solution can only be temporarily and needs to be integrated 
> into MediaWiki via a RSS feed that can be imported by other MediaWiki 
> installations (which will do the automated checkusage filtering locally on 
> their own on the imported RSS feed) and thus tracked by them.
>
> So at first we need to solve our current Wikimedia wide communication problem 
> and see how CommonsTicker performs, after that it needs to be coded into 
> MediaWiki and later if things have stabilized after a time in Commons we can 
> think of how to realize InstantCommons.
>   
This is a solution to a WMF problem. It does not answer the question; is 
our data Free to use or not but also, CommonsTicker and InstantCommons 
are not related.
>   
>> A summary of what happened is nice. It is not what I am really
>> interested in. What I am interested in is having things announced before
>> they happen. This will have, as an effect, that people do not have the
>> excuse that they did not know. They will have less reason to moan (they
>> will anyway). When you say nobody told us, you mean nobody told you.
>> Fine. This has been discussed at previous occasions when we had a flash
>> in the commons pan.
>>     
>
> See above. We have so many things to do daily it is impossible notifying 
> people in local wikis on a regular basis manually. And of course there are 
> also other people suddenly jumping into Commons (you never heared of them 
> before) and that just put thousands of images onto deletion request without 
> any debate or worse simply make mass image changes (and are as well unwilling 
> to share their points) and that make really *big* trouble if I stop them. In 
> order to get an impression how much energy it took for me making a proper 
> debate on a certain single issue see:
>  
> http://commons.wikimedia.org/wiki/Commons_talk:Licensing#Review_of_license_templates
>
> Well and for sure there are many more such people I can't be aware of and 
> ocassionally someone makes a general Commons-admins-flame on Village Pump and 
> afterwards we try to find out what he was flaming about at all and who was 
> the person that did something wrong...
>
> So there are two sides:
> * One side that makes trouble because we talk to much and do not delete fast 
> enough.
> * The other side that says we talk to less and delete too fast.
>
> Seems to me that at least one side must be wrong...
>
> The facts are:
> * Far more images need to be deleted in Commons daily.
> * Local unlinking of files and manual local notifications are such a huge task 
> no Wikipedian can imagine (really Wikipedians simply don't realize *how huge* 
> Wikimedia universe is).
> * Many people upload images in Commons without even interested in a minimum of 
> communication.
> * A tiny fraction of active Commons admins tries to catch up...
>   
You do not get my point. When policies are to be changed, when the way 
things work are to be changed, this is when you should inform the 
communities in advance. Some careful marketing communication is what is 
needed. Marketeers call it customer relations. And you /need /to inform 
your customers; when you do, you talk to all your customers when you 
don't you have to deal with them one at a time and you may find that 
customers do no longer give you their custom. Given how busy you are, 
you would not even notice.
>   
>> As to my definition of "profound"; changes in policy that affect usage
>> need to be communicated widely before they are finalised and implemented.
>>     
>
> Well I could have talked a lot previous to my many *very bold* changes in 
> Commons and wouldn't have come so far. I prefer in that case a model of 
> communication with some people I know, switching in my brain previous to an 
> edit of mine and and then simply do the thing and if something is not that 
> ideal hey we can sort it out afterwards. That's the only way how things can 
> efficiently get done in Commons.
>
> Regards,
> Daniel/Arnomane
Efficiently in Commons. Sadly there are these other projects and while 
many, myself included, applaud the hard work and understand its 
importance many others balk and refuse to use Commons for their 
material. Given your preference to limit your deliberations to your 
intimi, I am afraid this will not instil trust in the very people who 
refuse to use Commons.

Thanks,
    GerardM



More information about the foundation-l mailing list