2009/11/19 ThomasV <thomasV1(a)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
_______________________________________________
Wikisource-l mailing list
Wikisource-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikisource-l