<<< Date Index >>>     <<< Thread Index >>>

Re: naming scheme Poll: some individual comments



Mooo2,

I want to address some individual comments, too.

[=- Derek Martin wrote on Wed 24.May'06 at 20:54:22 -0400 -=]

> But even better yet, add a built-in configurator akin to what
> pine has.

Having one good idea should not prevent others from being
implemented, too.

> I'm actually in favor of cleaning up the variable names for the
> sake of consistency as well as aesthetics, but only as part of a
> major release.

Major it shall be: 2.0 .
But it's _not_ just for the looks, it _is_ useful to have
meaningful names so you don't have to look them up that much.

> I think if Mutt wants to continue to suck less than other
> mailers, this is the direction it needs to start heading... [to
> add more requested functional features]

Even though there might be something functionally that could be
added, I'd like to have better use of what is already there.
 That's what this is about. Mutt is already very good (and enough
ahead of others).


[=- William Yardley wrote on Thu 25.May'06 at  8:42:05 -0700 -=]

> When you start using mutt, there's a pretty steep curve as you
> figure out all the config parameters you need to set to get
> things to do what you want.

And this is exactly what this project aims to flatten.


[=- Stephan Seitz wrote on Fri 26.May'06 at 11:35:59 +0200 -=]

> No, users may omit some versions (e.g. go from 1.0 to 1.4), or
> users may test version 1.4, the config file will be migrated,
> the user goes back to 1.2, which has to handle now a too modern
> config file.

This is what section 3 of the manual is for: config by
mutt-version. It's in mutt since ... always?


[=- Rocco Rutte wrote on Fri 26.May'06 at 17:32:24 +0000 -=]

> >Anyway, other programs seem to manage to do it successfully...
> ...and most of these (and all I've seen) have mechanisms for changing 
> the config from the application and thus they have to. This is not true 
> for mutt (except shell escape :).

See above.


[=- Derek Martin wrote on Thu 25.May'06 at 21:41:50 -0400 -=]

> Thanks, it's nice to know that at least someone appreciates all my
> ranting.  ;-)

... I know how you feel. ;)
Thanks for your support, even though you want more and faster work
on mutt than I do now. Workwise the name change is simple.

> But IMO it's starting to look like the ham radio of mailers --
> it's kind of cool, but it's mostly used by a bunch of old guys
> (in Internet age, which is kind of like dog years) who just
> don't want to let go of the past...

I hope this is not the case...


[=- phyrster wrote on Thu 25.May'06 at 11:22:52 +0800 -=]

> the ultimate solution is a 'make muttconfig' interface.
> Supporting any of the 'convenience' or 'improvement' are evil.

So you say manuals are just for the developer nerds so they know
what they have coded and know how to make such configbuilders?
You deny end-users to use manuals themselves?

> But my 'gut feeling' tells me that this is very unfair for the
> experienced users and a waste of their time.

How is applying a script once "waste of their time"?
Why is it unfair to make "dev" users (experimental, "unstable"),
who should be prepared for changes, take this 1 change, too?

> hmm, kind of. Why should an end user have to ALWAYS read
> documentation in order to perform even the most common
> operations? or Why should they read the manual in the way they
> should with a textbook? We don't need diachronic reading of a
> long file and any reading should be kept minimal.

Right, exactly.


[=- Martin Swift wrote on Thu 25.May'06 at 16:27:50 -0700 -=]

> Both sides have made valid points, and this may sadly prove to
> be the greatest hurdle in this discussion.

To make the change easier for an individual there have been given
technical solutions.
Isn't it technically easy enough yet?

> I don't think we're faced with a question of what is right, but
> a matter of preference which inevitably is going to vary between
> people.

Yes, we do, see my long summarized response.

The problem we are facing is that people are too much concerned
that there _might_ be people out there, who either _might_ not
accomplish a conversion on their own at all or with great pains,
both keeping them away from using mutt, however ignoring that the
same people might know about the pain and still go through it
because of the functional benefits of mutt that it will still
possess (and even add for those sofar "stable" users upgrading).

So many people are overprotective or anticipating something
without factual ground.
This is what this poll is about: to see whether inviduals could
still accept the pain _just for themselves alone_.

It is unquestioned that it _will_ cause pain.
What we need to find out is whether a single _simple_ config update
will make you, you _alone_ choke.

If despite the pain "all" would say "I can take it this only one
time", then it doesn't matter that it is painful: it is supported.
So Thomas doesn't have to fear the flames that would come from it.

> So, is there any chance we can make a compromise between the two
> camps? Something like an improvement for newbies that involves
> the variable change and won't break configs (at least not right
> away).
> {...}
> The new ones could be introduced in an upcoming release. A later
> one would spit out a message to the terminal at startup alerting
> the user that (s)he is using deprecated variables, which ones
> have replaced them and that support will eventually be removed.

A transition time during which both variants work is already part
of the plan. It is Thomas Roessler who said the synonyms shouldn't
stay forever, to which I agree, so to have a well defined state once.

An intermediate "warning, deprecated use" release is a new idea I
don't object (if easily implementable ...).

> 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.

If you want to make manual improvements not at once but in several
steps (where I don't see the benefit), the name change should come
first now.
Since "stable" users would have to mess with their config because
of "alternates" + "use_envelope_from" anyway, for them it would
save 1 "painful" event if that were covered now.

> Seeing that the purpose of the change is explicitly to help
> newbies and making configuration easier, I don't think anyone
> think anyone will get kicked out of their hax0r clubs. ;-)

Huh? :)


[=- Derek Martin wrote on Thu 25.May'06 at 20:52:51 -0400 -=]

> You can even have the new version of mutt detect old configs,
> and run the conversion script automatically {...}.

No, users must pay attention to what they do.

> [*] Lots of users ARE idiots, and also lots of users ARE NOT idiots.

I agree.


[=- Martin Swift wrote on Thu 25.May'06 at 21:32:42 -0700 -=]

> 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.

No.
I believe anyone who dares to use "dev" and had enough energy to
subscribe to the mailing-list(s) should be able to take the "pain"
of applying a script once.

The problem is they don't want to vote just for themselves.
Instead they pretend to speak in the name of "all the other poor
souls that can't handle it" and spoil the result by taking it
before doing their vote.

> Would the time we are waisting not be better spent on
> contributing to the project?

Yes, for example by reading the arguments that have already been
written before and simply vote for oneself and get over with it.
Oh, and maybe even come up with solutions how to make it easier so
that the pain is "small enough" for people eventually to accept it.

> 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?

The advantages are laid out on the wiki, please read there.
They might not apply to your, but they are true: meaningful names
help getting things done easier.

How much outdated documentation qualifies to break this: 1, 2, 3,
... how many? Why do you care so much about outdated stuff instead
of focusing on _UP_dating that very same stuff?
If there are sites unmaintained, well d'oh, that's it then, they
are unmaintained and shouldn't be used anymore anyway. It's not
like they are the 10 commandments in stones god gave Moses.

Mutt has changed already a lot since its beginning, and docs from
this era are invalid, too, so what? Did it hurt mutt in any way?

> Really, how about putting that documentation effort into
> improving the existing documetation?

This _is_ part of improving existing docs.


[=- Derek Martin wrote on Sat 27.May'06 at 15:32:43 -0400 -=]

> The trouble is, as we've all pretty much been saying all along,
> there is virtually no benefit to existing users, nor any serious
> downside, so this debate really should not be conducted on
> mutt-users...

dev-users should have an easier time coping with it, it's rather
"regular" users who have difficulties.
There _is_ a benefit to existing users, that's why this belongs here.
As for the downside, that's what I try to reduce!

> This discussion really should have only been conducted on
> mutt-dev, amongst people who care about how Mutt is developed.

They care, but unfortunately they care more about convenience of
old users than generally good ideas or easier life of future
users. :-(
That's why this poll as started at all.

> But that natural opposition MUST be discounted, if the change is
> for the better, because it is a given. Compatibility must never
> be allowed to hinder improvement.

But this can be only achieved _with_ those users.
At least in this case where they are a key-argument in this
decision.

> And yes, the documentation is ANOTHER aspect of Mutt which needs
> to be improved, probably more so than the variable names. The
> great thing is, we can do BOTH. Imagine that?

Yes, think about this!


[=- Rocco Rutte wrote on Fri 26.May'06 at 10:32:20 +0000 -=]

> >In short, the benefit of changing names is minimal.
> 
> ACK.

Subjective, and since you are not in the position where you
appreciate such help (because you already have done your config,
don't need to look up anything anymore), you are no authority to
judge this.


[=- Shehu Dikko wrote on Sun 28.May'06 at 15:16:59 +0200 -=]

> First of all, it's a pleasant surprise to learn that mutt is
> attracting new users. How did we know this? I was under the
> impression that newbies went for gui-based programs.

How did you come to mutt? Have you been born with it?

> Have I missed a similar poll of newbies done to discover what
> specific difficulties they've faced? Just what is driving this
> review?

No poll, everyday experience on the support front.

> That said, anyone interested enough to try mutt should be
> willing to read and understand the documentation.
> What Gary says here should not be overlooked. Variable names in
> of themselves mean nothing if they are not properly documented
> and understood.

That has been covered on /Dicussion, please read there.

> The trouble with this poll is {...} rather it seeks my
> concurrence to ruin a vast corpus of currently accurate
> information {...}

See "outdated docs" above and on /Discussion.

> {...} not so as to add new functionality to mutt but merely in
> the *hope* that new information will prove less intimidating to
> new users. I do not think that this hope is a sufficiently good
> reason to make the proposed changes.

Experience, see above.

> If the aim is to aid new users, then they should be encouraged
> to start with the sample config. Once you know that they are
> going by it, helping them becomes a relatively simple matter.

Reading/using examples is being helped by meaningful var names!

> Whatever is finally decided, and I hope the decision is made
> based on a consensus arrived at after these discussions rather
> than the raw poll results,

I hope so, too...


[=- phyrster wrote on Wed 31.May'06 at  0:06:18 +0800 -=]

> > you naturally want to spend most of your time on your final
> > goal, whatever it might be.
>
> agree. 
> 
> So this poll is all about making mutt easier and it could be
> much better if mutt can come with a configuration wizard and
> sensible default settings (for example with gmail, send-hooks,
> attachments).
> 
> Let's vote for a change and take a look see where this change
> can take us.

Sometimes it needs just somebody to make a 1st step to start
things moving. This could be such a step.


[=- markus reichelt wrote on Thu 25.May'06 at 16:51:34 +0200 -=]

> He posted the poll here, so it might be a good idea to check for
> replies here too.

I do check, but I will _not_ vote for you.
The /Vote page is there to keep track of that.

> I won't use the wiki.

Why?


[=- cga2000 wrote on Thu 25.May'06 at 19:50:33 -0400 -=]

> Sorry for the [OT] - points #2 and #3 above - but then.. I
> didn't start it.. :-)

Try to stay focused, please.


[=- Nicolas Rachinsky wrote on Fri 26.May'06 at 13:34:50 +0200 -=]

> You can not know, wether a string constant is the name of a
> variable or something else.

Have a look at the /Script.
Of course it will never fit every exotic special cases, but should
work well enough.


[=- Derek Martin wrote on Sat 27.May'06 at 15:41:43 -0400 -=]

> Opposition to such a change has thusfar fallen into 3 categories:
> 1.  It can't be done.
> 2.  It's too much effort.
> 3.  There is no benefit, or too little benefit. {...}
>     there is also essentially no downside for those users.

Which as been covered on /Discussion in detail.


[=- Nicolas Rachinsky wrote on Sat 27.May'06 at 21:58:52 +0200 -=]

> If this change happens, mutt should be able to use the old
> configuration for some while (or refuse to work with an old
> configuration). But it should not change the configuration
> without explicit permission.

There is also section 3 of manual.

> PS:
> {...} but if it happens, it shouldn't annoy existing users more
> than absolutely necessary. And I don't like when the potential
> problems for existing setups are played down.

This is my concern, too. Did I appear otherwise?


[=- parv@xxxxxxxx wrote on Sat 27.May'06 at 23:20:43 -0400 -=]

> I like the idea of would be mutt refusing to work AT ALL with
> older configuration actually (with proper error message of course).

See above.


[=- phyrster wrote on Sun 28.May'06 at 15:53:30 +0800 -=]

> Just want to remind that people arguing here should also go to
> muttwiki and vote. Did my vote today and only saw about 20 votes
> altogether.

There are ~600 mutt-users, and ~300 mutt-dev exclusive.

I guess the reason for the weak participation so far it the very
same convenience many users show: it's too much effort to vote,
even if it's in the own benefit.

Think about it, if they would do it, they might as well accept the
change ... contradictory paradox... 

-- 
© Rado S. -- You must provide YOUR effort for your goal!
Even if it seems insignificant, in fact EVERY effort counts
for a shared task, at least to show your deserving attitude.