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.
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.
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. :-)
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.
Thomas