one more for the undecided
Moin moin,
I forward this from the newsgroup comp.mail.mutt for those who
aren't subscribed themselves, because it illustrates some points
about the proposal.
------ QUOTE BEGIN ------
Newsgroups: comp.mail.mutt
Message-ID: <e8dm3r$sve$1@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Peter H. Coffin <hellsop@xxxxxxxxxxxxx> wrote:
> You seem to have confused a curmugeony attitude with hostility
> to your cause.
I'm sorry if I appeared as being myself or taking anyone else as
"hostile". I see many people's reactions (like yours) the same way
as you do:
advocating "lack of need" due to not being the primary target
audience for the change.
I don't consider inertia [as] hostile, just making things more
difficult to overcome. ;)
I'm well aware of the difference as well as that "inertia" is the
case here.
> What I am saying, however, is that I learned without this thing
> you want to write or want other people to write, and many others
> did to.
Rest assured: _I_ would write that, even if all alone. I don't
ask anyone else to do it for me.
> A lack of a particular form of documentation is not a barrier,
> it's an inconvenience, just like inconsistant variable names are
> an inconvenience. Those that learn around that inconvenience
> have the knowlege then, and the convenience no longer matters to
> them.
Exactly, thanks for addressing this point! :)
Many things in mutt are for convenience.
Why did many things beyond mutt1.0 go into [/ change in] mutt?
Why do you use mutt > 1.0?
Why did for example the last 2 name changes go into mutt?
The change to specify an alternative envelope_from (in
"envelope_from", therefore breaking its former meaning as boolean
whether to use it at all or not) is just for convenience for
something that could have been achieved by workarounds through
"expert" use of $sendmail and/ or wrappers and MTA software.
Those who needed that badly could/ would have figured this
workaround out.
How many really _needed_ that change? The same with turning
"alternates" from a var to a cmd: how many really needed that?
Still _this_ was ok to pass and break people's configs.
What I've observed so far is that "fixing convenience" in
functionality/ code is OK, while the same for usability/ support
is not.
This makes me wonder: why?
My findings as already mentioned above: because it doesn't help
yourself (having passed the phase of messing around with/ learning
about configuring mutt).
So we are back to the original questions:
- does mutt-dev (or just the maintainer) feel responsibility for
providing adequate support for a fantastic product for newcomers/
beginners,
or is mutt reserved for the "elite" who already made and still is
required to make its own way through the tough terrain of learning
mutt to use it to the fullest of its functionality?
- Why not make it easier for our fellows to make proper use of
mutt faster than to have to take the same long time of exploration
as we had to?
Why not let them benefit by what we've learned to make it better
for them, in support, too, as we did already with code/
functionality? Or would you require all mutters to start with 0.92
and use [every] muttversion for the same time as we did before
allowing them to use the current functionality, so they go through
the same learning process?
------- QUOTE END -------
--
© 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.