Re: Poll: personal convenience vs. global improvement of docs
On Thu, May 25, 2006 at 08:52:51PM -0400, Derek Martin wrote:
> Criticising open-source software is like criticizing a democratic
> government... It annoys lots of people, but it is ESSENTIAL to the
> continued growth and betterment of the target of criticism. Hopefully
> the target remains worthy of thoughtful people taking the time to make
> such criticisms...
>
> Every word which follows is intended to be constructive.
>
> On Thu, May 25, 2006 at 04:27:50PM -0700, Martin Swift wrote:
> > On Thu, May 25, 2006 at 01:30:45AM +0200, markus reichelt wrote:
> > > * Gary Johnson <garyjohn@xxxxxxxxxxxxxxx> wrote:
> > >
> > > > In short, the benefit of changing names is minimal.
> > >
> > > I agree.
> >
> > ditto, but (and there is always a "but") ...
> [...]
> > I was sceptical of the move from the beginning and have to admit that,
> > though there are some good ideas out there, I don't think they
> > outweigh the frustration of broken setups that plenty of (mostly
> > non-technically oriented) people will face.
>
> I don't think this argument holds any water.
The part you quoted does not contain even a part of an argument. It is
a summary of my viewpoint which is based on arguments which have
already been presented.
> As I've already said, I believe if the transition is handled properly,
> the impact to users is very nearly zero.
But even if the impact is small, it isn't worth even this discussion
if there isn't sufficent reward. And here we get back to the little
bit that I wrote in my earlier email: No-one is accusing you of not
believing that it is worth it, they simply disagree. Not because there
is a fatal flaw in your argument, but because their view of on which
side of this line between effort and reward this suggestion lies
differs from yours.
You can battle this out, but rest asured that on such a small issue
you can easily flood the discussion and tire everyone out leaving
no-one to argue with you.
I really believe this is a small issue which will affect no-one much
either way it goes (which is why it is ridiculous that we are spending
so much effort on this). Would the time we are waisting not be better
spent on contributing to the project? Did you read the bit about the
bicycle shed that I sent in my last message? Do you really think the
names of variables will make or break this project? How much time will
you spend on writing emails about this? Is all this really worth it?
> If we're only talking about
> renaming variables, then there will be a 1 to 1 mapping of old names
> to new names. This mapping can be provided in a documentation file,
> and more importantly it will be SIMPLE to write a script to convert
> old .muttrc files to the new variable names. You can even have the
> new version of mutt detect old configs, and run the conversion script
> automatically (being cautious to save the old version, writing the new
> version to .muttrc-new-version-number or some such thing.
You can do all this and advertise it on CNN and go to peoples houses
and do it for them ... but it is still going to have to be done, some
might have minimal trouble, some documentation will be outdated and
other will have to be written or rewritten. For what? Different names
of variables?
> As for re-learning variable names, this also seems like a silly
> argument. Here's why:
I agree, but the following are also an argument *agains* the change.
> 1. Most variable names are just simply not remembered by the vast
> majority of users -- there are way too many of them -- and need to
> be looked up each time they want to make a change.
Which makes the names not really that important, right? Only a handful
of them will disambigue their purpose and one of them is really
misleading
> 2. If you've got a commented sample .muttrc, and a conversion script
> to change your existing configuration, 95% of the battle is won --
> you will already have what you need, PLUS a reference to the
> variables which you already had to change (the converted
> configuration), PLUS a documentation file which maps all the rest of
> the names to their new names.
Great, we'll have a reference and a documentation file for a change
that some would argue is mostly useless. Really, how about putting
that documentation effort into improving the existing documetation?
> If you really do remember the old
> name, getting the new name is simple. You could even have the
> conversion script spit the names out, so getting the new name would
> be as simple as:
>
> $ muttrc-convert --list |grep old_variable_name
> old_variable_name -> new_variable_name
It could even be as simple as with convmv which only lists what it
will do unless the --replace flag is added. However, without any gain,
even this is unnecessary.
> 3. Additionally, for people who are particularly obstinate about not
> changing, there is no reason both names can't be used
> simultaneously.
Exactly which is what I proposed as a compromise. Did you read my
email?
> I imagine the percentage of people who genuinely know the mutt command
> interface well, and would genuinely be significantly inconvenienced by
> such a reorganization of variable names, is extremely small. Those
> rare few people are mutt's uber-users, and such people should, I
> think, expect to be inconvenienced by changes in the name of making
> better software.
I agree on the numbers here. I, however, think it is the experienced
that will be the least inconvenienced by this. Thanks for your
concern, though.
> I honestly don't mean to be insulting, but I just can't see how this
> is a real issue, except for people who are excessively lazy or
> excessively brain-dead, or people who just oppose change for the sake
> of being obstinate.
Here I could say that I don't mean to be insulting and then proceed to
call you an idiot -- but I was taught that in a debate it is not only
unnecessary, but hinders debate.
Why would I even think of calling you such derogatory names? Because
I'm an obstinate, brain-dead, lazy luddite? Or, because here you are
badmouthing people that have given their oppinions when asked and
critisised ideas constructively. Something you seem to like when
justifying your own verbal diarreah (attempting to give it a lofty
ambiance by comparing it to democratic discussion).
> > As this won't do a lot of good without the documentation, how about
> > improving it before diving into the change? There could be a todo list
> > of critical items that needed to be added and changed before changing
> > the variables.
>
> A todo list goes against Mutt's development philosophy of not having
> any sort of strategy or roadmap... :-D
<http://en.wikipedia.org/wiki/Straw_man>
A list of critical items, needed for a small tile in a softwares
road of developement to be at all useful, is neither a stragegy nor
a roadmap.
> OK, that last was mostly just a dig partially meant in jest, but
> there's a kernel of contstructive criticism in there. In case this is
> lost on the reader, whatever else you think of me and my opinions,
> please understand that the reason I am so vocal and occasionally harsh
> in my criticism of mutt and its current design trends is that I
> genuinely do care about the quality and future of this fine piece of
> software, and hope that my strong words encourage people to think
> about what is on the table, and strive to make mutt ever better,
> rather than just what's convenient right this moment...
Are you really suggesting that those that disagree with you cannot
have the same motives: those of care for the project over their own
convenience?
For someone that speaks so highly of debate you don't seem to conduct
it very well.
> The prevalent
> attitude here appears to be, "don't break compatibility, no matter how
> much better the software would be," which I will remind you is one of
> the biggest reasons most of you don't (want to) use Microsoft Windows
> today. That design philosophy leads to software that sucks. Period.
Another straw man. I disagree with your interpretation of the
prevalent attitute. I think it is more: "don't do pointless things
that will waste time and potentially break compatibility and cause
users problems".
Derek, I was going to comment on more things from you email that I
thought incorrect, ineffective or uneccessary for this debate, but I'm
already late for meeting some friends for beers for a graduation
celebration and, frankly, this isn't worth it.
Have fun typing, driving away any dissent.
The rest of you, ... *sigh* ... sorry.
Martin
--
\u270C