2009/11/19 ThomasV
<thomasV1@gmx.de>
Cecil a écrit :
>
> Have you actually read anything that has been said before? We don't
> accept the discrimination of the IPs in our community.
However, you accept the fact that IPs are not allowed to upload files.
As a consequence, IPs are not allowed to start a new project at de.ws,
because the rule is "no scan, no text". You never complained about that.
Could you explain why ?
More generally, there are dozens of things that IPs are not allowed to
do in MediaWiki.
First of all, images are uploaded on a different project and I have to accept that there are different rules.
But it does not really matter:
The IPs at German Wikisource are able to start new projects. We have a few accounts for uploading the images to Commons. Several of the registered users also never uploaded images to Commons despite starting projects. After all we are a community and we work together.
> To your second option: how long will that work? With your next update
> you will most probably break all local programming again. And who
> should repair it each time after it is broken?
You seem to believe that I break things on purpose. This is not true.
When I was maintaining code at de.ws, it is true that the local
javascript sometimes was temporarily broken because of software updates,
and that it had to be adapted. However, I was the person doing this, and
I spent many hours just for de.ws. Maybe you could acknowledge this.
I acknowledge that you spend a lot of time working on all that stuff and I believe that you are not breaking stuff on purpose. I believe that it is negligence.
The problem is that you seem to usually work without consideration for other parts of media-wiki (like when PR2 suddenly didn't create any headers/footers anymore just because I had a different language for my UI). And you either don't test your updates at all or much too little. Testing when something is already active is not testing anymore (the programmer and his tester are responsible for quality code, not the customer in RL-environment). Then it is too late and the end-user has to suffer under it and then you have to understand that after seval of those occurences you will not meet any thankfulness anymore.
The second option that I mentioned means that you keep using
ProofreadPage, without using the pagequality system that you do not
like. However, if you do not trust me, if you really believe that I
break things on purpose, then you should not use my software at all.
> We now have found a user who can program in php (that's why we have
> the patch), but at least I don't know anyone for JavaScript since
> Xarax is gone. Or can you guarantee that with your future updates you
> will not destroy it or that in that case you will repair it again? And
> how are your plans for future development look like? Do you actually
> have any plans to let us know now what features/surprises we can
> expect in the future? After all until now your concept was to let us
> know about a feature on the day of the update, usually at a time when
> we already noticed that there had to be changes because something
> didn't work
Indeed I do have plans for future developments. I usually discuss them
with the people on IRC, and at ws.org. Sometimes new javascript features
are tested at fr.ws and en.ws, before I move them into the extension's
javascript. Once new features are added to the code, they are publicly
visible in svn, weeks before their activation, just like any other
developer's work. Every software modification at Wikimedia is public.
However, I cannot make announcements in every language, and for the last
few updates I did not make the effort to write in German.
New developments imply new bugs, and some maintenance. This is normal. I
try to do my best to avoid bugs, but nobody is perfect.
If you are scared about future developments, if you want to use software
that is perfectly stable and frozen, then you should not use
ProofreadPage, because there will be future developments. I could even
add that if you want to use something perfectly stable, then you should
not use MediaWiki at all. :-)
Nothing is ever really stable as long as there is development done. Actually even after development has stopped (users are creative). But I expect enough quality work that updates cause minor glitches or are removed again. And at least at German Wikipedia this usually is the case. The only real problems I ever had when working on Commons and Wikipedia were when the tool-server didn't work anymore and that has nothing to do with media-wiki.
And if you ever announce something on
ws.org earlier than the day it is added then you hide it really well. The only information one can find there is either still in theoretical maybe-state or 'was just added'-state. So there is no project management on your side at all. IRC is no project management. If you wanna see how to not surprise users then check
http://de.wikipedia.org/wiki/Wikipedia:Projektneuheiten (the points 3 and 4). If a programmer properly plans his work and not just hacks away then he should have no problem doing that kind of list. And obviously most programmers working on WP-updates plan properly. AFAIS it is just you who usually announces just after the fact.
And that kind of total unreliability (yours, not the codes) makes it impossible to work on anything which has your work as a base. Expecting people to be 24/7 in IRC is no way to communicate SW-changes.
> In any case (your second option or us forking the extension) I would
> be very much for getting rid of the buttons. The reasons for it I
> already mentioned even though there was no reaction to it. They are
> after all very unfriendly when it comes to one very important
> principle of web-programming: web accessibility. Even if you are not
> disabled you have to click on them and look in the edit summary to
> learn what they do. But if you are disabled then they are a nightmare.
> And yes, I already had to explain to a user how to find them by
> theoretically parting the monitor in fields and telling the user in
> what field to look. And he was not even colour-blind in which case the
> buttons would loose any worth anyway (two buttons are red and one is
> green, by far the most common trouble-colours of colour-blindness).
sorry, but I did not know that you find these buttons unfriendly. If you
are color blind, you can modify your CSS to change the colors, or to
replace them with icons. I already explained how to do this in de.ws. If
the problem is not color, but how to access them with keyboard instead
of mouse, it is something that I can improve. I just need to know about it.
Now Cecil, I am very often available for discussion on IRC. I say this
because you don't seem to be using this. However, the type of
communication that you can have on IRC is very different than on a
mailing list or wiki; some misunderstanding can be avoided by a more
direct type of communication. I am willing to find a solution to your
problem, and I would love to discuss with you more directly. The reason
why I rejected your patch is not to harm you; I did this in order to
protect the tool that I developed.
Correct, I don't use IRC at all. But incorrect, it is not my patch. The only script-language I used in the last eight years is Tcl.
And AFAIK all code here is open source, which means that everybody is allowed to change it. Maybe you shouldn't programm stuff in open source if you don't like other people wanting to make it useable for themselves. So it really seems that forking the extension is our only possibility.
Thomas