--- Timwi <timwi(a)gmx.net> wrote: > Andrew Dunbar
wrote:
> There's no need to be short-sighted and settle
> for quick fixes just because they are "a lot
> easier". I'm sure that's not the kind of
> thinking employed by the founders of the OED or
> Websters.
>
> If Wiktionary is a good project, and I'm sure we
> all believe it is, then it will survive long
enough
for the real
fixes to come along.
This is so typical. This argument is always going
to brought up for everything that is not a
complete miracle cure.
Hence nothing will ever change and hence we will be
stuck with the same problem forever just because
people wouldn't accept at least a partial solution!
So basically you have made a prediction that
nothing short of a miracle is capable of fixing
the problem the proper way. Then you extend
this into the future of all problems for all
eternity. And this is to bolster support for your
compromise solution.
From what you say in the following paragraph, it
seems that you expect these statements to be taken
as grounded and probably true:
Cleaning up
after the side-effects of the quick
fix and cleaning up again in the future when a
solid fix comes along will be a pointless drain on
the time and patience of the contributors.
That is ungrounded and probably false. What you call
a "quick fix" is a step in the right direction.
Any "cleaning up" needed to do after the next fix
(whether or not it is a miracle cure) will
complement, and not override, replace, or render
useless, the cleaning up needed now.
Since you have brought up "grounds" and
true vs. false regarding the nature of your
proposed change and its side-effects, I would
call on you to please provide some grounds
to support that these claims of yours:
a) that a real fix require a miracle
b) that cleaning up won't be required
Also, going
with the quick fix now will reduce our
chances of getting the developers to implement a
solid fix later on, because they will believe they
had already fixed the problem.
You are forgetting that you already have no chance
of getting a developer to do anything.
This is your argument, for which I am hoping
you provide some grounds.
The only reason why we can do this now is because
*the feature is already there*.
A feature with side-effects which, thankfully, have
now
Been discussed and commented on by several people.
I don't know why it was written (maybe for Toki
Pona?), but we have it now, and we can flip a switch
to make it work. I (not really a “developer”) have
volunteered to write a script to do the moving in
order to spare you from 40,000 page moves, but even
without that script I am sure the Wiktionary
userbase can fix all of that manually over time.
So you do know the switch is there. You don't know why
the switch is there. You do know that a miracle is
needed to make a better switch. You're not really a
developer. You will write a script. Such a script does
not need to be miraculous. My claims that cleanup
after the script are ungrounded. You are sure we can
avoid this non-developer script if we fix it ourselves
over time. You are not prepared to wait time for a
better fix.
> It may be even more unfortunate that some feel
the
> need to put down others rather than improve their
> arguments or consider that other opinions might be
> valid and not just the "contrary ignoramuses" who
> have been depicted in the email I'm replying to
> now.
I do think I have considered the arguments brought
forward. I have thought about them as much as I
could, and almost all of them struck me as separate
issues that were not arguments against this
particular change.
Well I hope I've clarified what hasn't been thought
about Sufficiently. In the meantime I'm going to start
looking at The Wiki code, and get in touch with some
Wiki developers to see how feasible a good solutions
would be.
Hippietrail.
___________________________________________________________ALL-NEW Yahoo! Messenger -
sooooo many all-new ways to express yourself
http://uk.messenger.yahoo.com