"change varnames" summary (was Re: feature freeze?)
Moin Thomas,
=- Thomas Roessler wrote on Mon 14.Aug'06 at 21:38:29 +0200 -=
> So, what else -- except for a bit more public exposure of this
> or the next version -- do we need before 1.6 is ready?
Public exposure is a good keyword.
I know you're very busy generally, so I'm patient with answers,
nevertheless I hope you'll give some ... soon, now that the heat
(of summer and discussion) is over.
Recapitulating concerns, opinions and answers given so far (or not
given) by any interested party, some questions are still left open.
Therefore I try to put things together in a simple form.
What we have:
- 2 vars change of "alternates" and "envelope_from".
=> already upcoming disturbance.
=> shows attitude of "more user-friendlyness" without
"technical necessity".
- pgp,smime,imap,pop,ssl prefixes.
=> again shows right attitude of "more user-friendlyness",
this time by "consistency&structure" over lazy
shortnames.
- some more vars in need of rename in itself.
=> opportunity to combine more benefit with already
upcoming disturbance.
- all vars with prefixes.
=> opportunity to continue consistency and combine more
benefit with already upcoming disturbance.
This makes:
You have shown that you _do_ think in favour of user-friendlyness
over whatever kind of convenience (not to break stuff or short
names), you have now the opportunity to get more benefit in terms
of user-friendlyness out of the _hard_ break with relatively small
additional disturbance.
"2 vars" vs. "some more/ all" : who wins for the mutt-community by
X - break impact, disturbance
X - benefit, demand
X - necessity
X - numbers of victims
X - annoyance
"all" wins over "2 vars" in all categories, see below the details
of each. If you feel a category is missing or the result wrong,
please tell me which and how.
Otherwise please explain the "double-standard" for the already
existing signs of user-friendlyness against the "fix of all".
If you're worried about the required work of code editing, script
support (it's done and _works_!!!) and announcement campaign, don't:
I will do it with the helpful bunch from the mailing-lists,
continuing our work on the whole manual in general to make it more
user-friendly as a whole, and with it mutt.
The varnames themselves beyond the descriptions around them are
part of the documentation/ support. 2 of them are being changed
with the next release anyway, breaking configs on their own.
Several others are simply too cryptic to get the idea, especially
when they are sparsely referenced in the manual (like "hdrs", and
too techy == unintuitive for "average" users like "spoolfile",
"folder" or "mbox").
With the present circumstances some things could be combined
bringing more benefit than the 2 original changes for nearly no
extra cost:
none for the coders/ maintainers (you), none for most users,
little for a few, and little more for a very rare few (with
exceptional configs who can deal with it by their skill).
Not only does "all vars" come out better in comparison with "2
vars" in absolute numbers, it also helps cover the break with its
support + campaign and improves the benefit/cost ratio altogether.
Let's make a fine tool more user-friendly!
Please continue the spirit shown before!
------
Detailed comparison of "2 vars" vs. "all vars":
- breaking 3rd party docs
- happened before (see pgp-vars and other examples
producing synonyms).
- will happen now again for the 2 vars.
- maintained sites update, official ones are reference,
others are nice to have,
but unmaintained shouldn't be relied on anyway.
- not unique to the "naming scheme" change == equal.
- breaking configs of many "victims" = defined as
must do extra work for no personal gain.
"it works fine as it is, feature not needed for me"
Nevertheless both changes have their target audiences for
which they are useful _even though_ not needed nor for all.
- happened before (see pgp-vars and other examples
producing synonyms).
- will happen now again for the 2 vars.
- not unique to the "naming scheme" change.
_BUT_: "alternates" is a _hard-break_!
No synonyms help there => no transition => _must_ change
=> fail with upgrade!
- benefit, demand
- for 2 vars:
convenience for just a few _rare_ cases, which
goals can be achieved with workarounds with
existing version.
- other vars:
intuitive use just by themselves, easier to search
for/ find in docs.
- "naming scheme":
- none for veteran users with "working" configs,
- help for all others still or who _will be_
working with their config and manual,
especially to find vars, like with
existing prefixes.
- necessity
- for 2 vars:
"alternates" only for _very_ few exceptional cases.
None especially for "envelope_from", could have
stayed since "envelope_from_address" was merely
_added_, yet still it was changed for ...
why exactly? User-friendlyness?
- other vars:
_at least_ the same necessity of user-friendlyness
as for the other 2, so: Let's continue!
So there is already a lot that should be changed
on its own. While at it, the naming scheme doesn't
add work anymore.
- "naming scheme":
- none for veteran users with "working" configs,
- necessary for casual/ single var seekers _not_
reading whole manual, looking for _quick_ solutions.
(There are a lot of those working by the names
first/ only, not paying off to RTFM as whole for
single items)
- numbers of "victims" vs. non-"victims"
- with 2 vars change will be more "victims" than not (using
"alternates", "envelope_from", or both), because
they are important widely used features.
2 var victims > 2 var non-victims
- "naming scheme victims" are only those within "2 var
non-victims", i.e. those having to change already
for the 2 vars change which _is already going_ to
happen or not affected by "2 vars". "2 vars victims"
therefore don't count as "naming scheme victims".
So besides better absolute numbers it's even a
better ratio:
2 var: "victims" > non-"victims"
=
naming scheme: non-"victims" + "victims"
"2 var" victims "all var" victims
--------------- > -----------------
all all
The 2 var changes are still to come for stable users (dev users
don't count for changes, that's what dev is for: to save stable).
It would mean no extra effort to apply a script rather than to fix
manually, meaning the "2 var victims" are no "naming scheme
victims".
The script works safe (-> try!).
Instead of just mentioning that it fails on _exceptional_ cases,
rather be constructive and point those out so they can be fixed!
Unsavable exceptions will still exist, but then they are produced
by skilled users who can deal with it swiftly and are _very rare_!
- disturbance
- as with all unnecessary but useful changes in the past,
the 2 vars as well as the "naming scheme" is only painful
at the introduction and is quickly thereafter forgotten,
but in the long run it pays off.
- whatever technical concerns apply to the "naming scheme"
changing nearly all vars, they apply with same quality to
the changes of the 2 vars alone already, they are not
additional problems.
Only that with the given support by script and
announcement campaign for the "naming scheme" along with
general docs improvement by several people it will be
smoother!
Remember, the "alternates" break is a _hard_ one, see
above in the "break configs section".
No safety net: update => fail!
- annoyance
- The discussion and vote has shown that people are not so
much worried about the change itself but how it's
conducted. They are not worried for themselves but
rather "the poor others". But they are ignoring that those
"others" would actually _better cope_ with the upgrade of
the "2 vars" (particularly "alternates") by the help of
the script and campaign support rather than without.
Experience (not only TLR's, but also in #mutt) has shown
that the hard-break of "alternates" introduced "sneakily"
hits more users badly than asking them to apply a script.
It's a syntactical change, not a mere synonym!
The "sneaky" approach will cause friction and annoyance
when users hit it, crash hard head first on the break.
=> Instead make big noise about the update with help of
"naming scheme" while making it smooth with its offered
support of script + campaign.
Besides, discussions with people that have _not_
participated in the public discussion and vote (the
"silent crowd") have reported that they are not "scared"
enough of this change to oppose and could very well "roll
with it" if it came along.
Note, participation was like 30 of 600 ML subscribers and
a few UseNet readers alone, and even among those were like
3 really opposed for their own sake. This is like 3/600,
0.5% who are seriously and reasonably concerned.
So, the original prejudice that it won't be accepted is
unreasoned to claim there will be significant opposition.
With helpful people and the support and preparation it
will be well. With the input and ideas produced by
feedback to the proposal this can be done _smoothly_, and
with it help the hard-break.
Yet you prefer to let the 2 vars hit the crowd as hard as dev
users over a clean cut relaunch with varnames
scheme and its support. Why?
Good software with well usable docs "sucks less".
Docs where you don't find or badly (have to read all) are not
useful.
The tool is only useful when its features are known.
Make this knowledge easier accessible, so that ideally a simple
"rtfm" is enough to make people find what they need on their own.
Major harm is done already by "2 vars", not by "all vars".
Even though "all vars" means absolutely more total victims, it
improves the gain/cost ratio immensely and offers better support
to cover with the upgrade.
current user harm by 2 vars: 100, 1000, 10000?
benefit: 10, 100, 1000?
ratio benefit/ harm = 1/10
current user harm by "all vars": +100%?
benefit: current users bulding config : +200%
_FUTURE_ users! : 1000, 10000, 100000
ratio benefit/ harm = 20/1
Just try, see how it works, let's make it better, until it's
smooth enough to make it succeed.
As part of "naming scheme" relaunch 2.0 the "2 vars" won't be
noticed as much as outstanding annoyance in itself, but part of a
big change for better support in general.
--
© 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.