Changes between Initial Version and Version 1 of VarNames/Discussion


Ignore:
Timestamp:
Feb 5, 2012 1:00:16 PM (6 years ago)
Author:
rado
Comment:

migrate wiki.mutt.org

Legend:

Unmodified
Added
Removed
Modified
  • VarNames/Discussion

    v1 v1  
     1[[PageOutline]]
     2== Add pro/contra arguments as you see fit ==
     3=== Read them first before you add: avoid duplicates! ===
     4And keep it simple!
     5
     6== Pro: why do it at all ==
     7
     8=== easier support (do-it-yourself + helpers) ===
     9
     10Easier use -> more popularity, might gain even more momentum for development.
     11----
     12Good software == code + docs.
     13[[BR]] '''Improving software''' means not only improving features, but also improving their usability for newbies.
     14----
     15'''The pain of "dev" users due to "alternates + envelope_from" is still going to hit "stable" users!'''
     16[[BR]] Think of how the "regular" users will react, when already the "smart" ones using "dev" version complain for "such small changes".
     17
     18 * Why force them to go through '''the same hell'''?
     19 * Why not '''instead''' ease the pain of those offering a one-action script to transform their configs '''easily, automatically'''
     20   instead of forcing them to go through it ''manually and for at least 2 cases: alternates + use_envelope_from''?
     21 * When you '''already have such a one-action script''', changing _any_ number of vars means '''_no extra_ pain.'''
     22And make '''BIG WARNINGS/ ANNOUNCEMENTS'''.
     23
     24Considering the changes since 1.4.x call the next official release '''"mutt 2.0"''', kind of "relaunch" (instead of muttng. ;-).
     25This possibly can add to the "note this" factor (maybe along with hitting news magazines like heise.de).
     26
     27----
     28'''"It might have been a good idea 8y ago", well, it _STILL_ is a good idea!'''
     29
     30 * Even though established configs would have to change, time doesn't change the idea's usefulness for new users.
     31 * There will always be '''more new users than old configs''', afterall every oldie has to be a newbie once.
     32 * There will '''always''' be new users, while '''now''' the ''current'' old users will die out over time.
     33  * It's '''NOT a lifetime job to adapt''' the changes for users, it's a one-time event and it will be (relatively) simple.
     34  * But it will be a mutt's lifetime benefit!
     35
     36----
     37'''If it changed would you stop upgrading or even using mutt?'''
     38
     39Since no code is changed, mutt still keeps its features! Once this single change has passed, all will be fine again.
     40[[BR]] '''BUT''' newbies and/or casual users who don't find the stuff they are looking for might give up on mutt.
     41
     42----
     43'''Balancing numbers of affected users:''' Too many old users would have to change their old config.
     44
     45Let's see how many people are affected in which way:
     46 * various types of '''(many) manual users''':
     47  * casual, read all, read never (because meaningful names examples enough), read single/ few items.
     48  * '''ever growing''' number of newbies.
     49 * many '''_unheard_ STABLE''' users '''still facing upgrade''' with "alternates" + "envelope_from",
     50  * who'll certainly '''"complain"''' as much as if not more than the "dev" users already,
     51  * which could be '''helped''' with this /Script, and then number of changes doesn't matter.
     52
     53'''VS.'''
     54 * a '''fixed''' number of one-time changers ("dev" users) who should be able to cope with it given '''announcement''' and VarNames/Script.
     55 * unskilled users '''with''' customized config '''not''' containing "alternates" nor "use_envelope_from".
     56
     57Those can't be expressed in numeric values, but compared to only the '''_fixed_ current''' numbers, they will outgrow the latter.
     58Ultimately the '''everlasting growth''' of newbies having a useful manual '''plus all the stable users to UPGRADE NOW''' wins by length
     59against the '''current''' number of '''"dev" users and unaffected by the 2 vars stable users''',
     60who'd be the only ones to make an '''extra change'''.
     61
     62Most '''"stable"''' users have to change anyway!!!
     63And those "dev" users are "mature" enough to apply an update once, as they already had to be for "alternates+envelope_from".
     64
     65That's the '''PURPOSE of "dev"''': to be spearhead for changes!
     66That's their risk to have to do more work than stable users
     67and to learn '''what can save stable users''' so they don't have to go through the same pains.
     68"dev" user aren't allowed to complain now to "have to do more" than "stable users", it's their "job".
     69
     70----
     71----
     72== Contra: why not to ==
     73
     74=== It hurts too much ... really? ===
     75
     76'''It's too much pain. The balance is about the cost to *every* deployed installation.'''
     77[[BR]]'''You basically force work on users by being non-compatible.'''
     78[[BR]]'''Changing a lot of stuff pisses people of.''' (whole config)
     79
     80tlr (Thomas Roessler the mutt maintainer) referenced the "alternates" case:
     81''I already get hate mail about the incompatible change to alternates. Don't even think of changing ALL variable names. ;)''
     82[[BR]]''In the case of alternates, I was convinced that the benefit was worth it.''
     83
     84 * It was/ is, it just caught many people '''unprepared, by surprise'''!
     85 * Improving support for future users doesn't come without changes, and changes not without some '''collective effort and personal commitment/ sacrifice'''.
     86 * There is only a '''single action''' involved to transform a given config with the help of the /Script.
     87 * See above in "PRO" section, point "good idea": '''stable''' users are '''still going to suffer''' the same as '''dev''' users already have:
     88  * learn from this, don't let them go through the same hell!
     89
     90----
     91
     92'''Global renaming just to make it prettier, I don't buy it.'''
     93[[BR]] '''Rename doesn't help, people must rtfm anyway. Better improve docs instead.'''
     94
     95 * This '''is''' improvement of docs since variable names are part of the manual and orientation within it!
     96 * '''Experience says it does help'''! Gained from IRC MuttChannel, on mailing-list mutt-users and the already received feedback to this poll.
     97 * '''There ARE users that benefit'''. So while maybe you '''personally''' don't see the benefit for yourself (since you're a veteran user), it still exists for others!
     98  * Varames are '''important''' for newbies _not_ reading (and not required to read!) the whole manual to find a quick/ simple/ small solution.
     99 * It's not about the looks, but the usability: '''do you require users to read the f*** manual EACH TIME for each SINGLE SMALL ITEM'''?
     100  * When the manual is '''too big''' (like mutt's), it helps finding stuff if you can limit the search range to a "related" area (or exclude).
     101  * The names themselves might help already instead of reading desc. of each single feature in hopes it might have a connection to the original problem.
     102 * It helps understanding examples '''without having to lookup in manual''' to get an idea how they affect a given part!
     103 * Meaningful names help '''getting an idea where to look at all''' before you can RTFM.
     104
     105----
     106'''In short, the benefit of changing names is MINIMAL. Who benefits from it?'''
     107[[BR]] '''Varnames you are used to you remember, others don't matter.'''
     108[[BR]] '''muttrcbuilder + good docs is enough, names don't matter.'''
     109
     110 * '''WRONG'''! While it might be true to you, this does '''not apply to everybody else'''!
     111  * If you are not a newbie yourself, what is the basis for this judgement?
     112 * If this _is_ true to you, then the only thing you FEAR is applying the /Script once?
     113  * A good config tool (whether internal or external) doesn't release you of a '''good _reference_ manual''' for those not matching _your_ user-profile.
     114 * '''The benefit is not for those who don't use the manual anyway:'''
     115  * Those who have 100% memory like you who can remember (_all_?) varnames.
     116  * Those who have a fixed config and never change _ANYTHING_.
     117 * '''This benefit is for all those who _must_ use the manual:'''
     118  * NEWBIES/ first contact users.
     119  * Casual users, who incrementally develop config.
     120  * Single issue problems (few things of the mostly useful defaults need to be changed): '''it is a reference manual''', dammit! ;-)
     121  * Veteran users pointing newbies what to RTFM.
     122
     123----
     124'''It's not worth the trouble for all the old users'''.
     125
     126 * "alternates" + "envelope_from" must be changed for '''stable''' users anyway, already breaking configs, examples and docs!
     127  * '''When they have to be fixed anyway''', then why not do '''all the stuff right!?''' Some current names just aren't intuitive.
     128 * Instead of refusing it "in the name of the current users", '''let them decide for themselves'''.
     129  * You are not their representant: while you might not want to take the trade-off personally, '''they might consider it not too painful!'''
     130  * Don't vote on their behalf! '''Give them your reasons on here this page''', not your vote! Those others '''are''' considered by the reasons!
     131
     132'''NOTE:''' the goal of this poll is not to figure out whether it helps or not or how much it helps them others!
     133[[BR]] The goal is to figure out whether '''YOU''' personally will '''accept''' the one-action '''change'''.
     134[[BR]] '''Just for yourself alone and not anybody else: don't second-guess!'''
     135
     136 * '''Second-guessing''' the outcome before the actual results to support a '''phantom majority''' spoils the purpose of this inquiry:
     137  * If '''all oldies for themselves''' accepted this for ONCE, why vote '''against them in their name?'''
     138
     139----
     140'''Longer var names intimidate users looking at examples and make them harder to remember.'''
     141 * Does it hurt more to see names, which are increased '''just by a single word''', or does it help more when you have a better grasp of what it does?
     142 * Is it harder to remember a 1 or 2-word longer name than a '''cryptic''' one, where the meaning is not obvious?
     143
     144----
     145'''Prominent announcements are missed for automatic updates.'''
     146[[BR]]'''Automatic updates will fail.'''
     147[[BR]]''example: apt-get dist-upgrade, and there goes your configuration? No good!''
     148
     149 * This will '''already''' happen '''without the naming scheme anyway''' thanks to the already approved change for "alternates"!!!
     150 * There are '''"post-install" scripts''' for exactly '''this purpose''', so the /Script can cover up the '''hard syntax break''' by "alternates".
     151 * '''Maintainers (distros and sysadmin) are required to keep track''' of NEWS or CHANGES with BIG WARNING signs with any upgrade,
     152 * so that they in turn can then inform their users about conflicts within their own distro info system and advise them how to fix.
     153
     154----
     155'''"Please run /usr/share/doc/mutt/fix-my-configuraiton."  And btw, your configuration isn't portable anywhere.'''
     156
     157 * '''Config already is not portable anymore''' thanks to "alternates"!!!
     158 * Changing all vars with a /Script is less work than 2 manually.
     159
     160----
     161'''You invalidate a lot of existing knowledge that is out there on the net, guides + examples.'''
     162
     163 * The knowledge is not lost, it can be '''collected, corrected and offered at a central place like mutt.org'''.
     164  * This is where people come to look first anyway, no?
     165 * '''They already are wrong''' for "alternates" and "use_envelope_from" and some more other changes, because they aren't updated:
     166  * "guides" are well advised to be updated already anyway, and when you have to go through, you can aswell do it for all (per script).
     167 * Maintenance means updating from time to time: unmaintained systems are quickly outdated anyway.
     168 * Preventing a "good idea" in favour of already outdated and unmaintained examples doesn't sound like a "good idea".
     169
     170----
     171'''Before doing a fork, you could try to discuss the proposed change on mutt-dev and/or mutt-users and use that as an indicator.'''
     172
     173 * This is what these pages are for, but a fork is missing the point: it's a '''documentation''' problem, '''not''' a '''code''' problem!
     174 * If the change doesn't apply to the '''"official" docs''', people won't use any fork just to have "pretty" names '''while all the main docs+examples about it don't apply'''.
     175 * It has to be a collective '''_official_ effort''' to bring the desired benefit, because that's '''where people look for docs first''': the official mutt.org!
     176 * It's not about creating a new product and/or community, it's about '''improving the support for the existing one'''.
     177
     178----
     179'''Don't change all at once, make small steps ("by erosion").'''
     180
     181 * This task must be done all or nothing for a categorized and sorted list to be of use for newbs to make their way on their own.
     182  * It must be complete, whole at once: step by step makes no sense.
     183 * It would require too much patience and awareness by too many people to stay in line with the new naming scheme when it takes too long.
     184  * That won't work out, people will "mess" around again, never to reach an end.
     185  * This would rather mean pain with no end. The other way it's truely a big pain (or not as big with script), but it's over after one step.
     186
     187----
     188'''There would have to be synonyms.'''
     189[[BR]]''These make configurations less understandable (because there are multiple ways to express things), not more understandable.''
     190
     191 * But '''only the documented names are the authorative (supported) ones''' to rely on, that's what docs are for afterall.
     192 * Synonyms for a transition are just that: until they expire, '''even CURRENTLY USED synonyms are NOT documented at all!'''
     193 * No more synonyms, no more confusion: "Hey, this var XYZ doesn't work?!" => "It's dead, Jim".
     194
     195----
     196'''Must keep compatibility for long transition time.'''
     197[[BR]] ''Yet still all synonyms must be documented so people know what changed.''
     198
     199 * Period need not be too long: introduce now with next release, old stuff gone by release thereafter:
     200  * the last release step can be deployed faster than from 1.4 to the next release if needed to get rid of synonyms support faster.
     201 * A simple list of what is translated to what should suffice, no?
     202  * With a script that should be easily done (or even look at the script itself, it will be there anyway).
     203 * BUT '''why would a long compatibility time hurt?'''
     204  * '''There are already ANCIENT''' synonyms about which nobody complains, neither being used in configs nor being undocumented!
     205
     206----
     207'''A number of mutt users will struggle to migrate their config!!!'''
     208[[BR]] '''I'm sorry, but I don't expect any sed/awk/perl/logo script to work seamlessley for all.'''
     209[[BR]]'''Bear in mind that not all Mutt users are technical and/or subscribe to mailing lists and newsgroups.'''
     210
     211 * True, there is the point that admins will have to take care of their users who don't do tech-stuff themselves.
     212 * But if they truly are not so much into "hacking", then they probably don't have configs that would fail with the /Script ('''it works, just try'''!),
     213  * which the admin could run for them once or they themselves.
     214
     215----
     216'''There are other MORE important things TO DO ABOUT THE MANUAL (like sane defaults and other).'''
     217
     218 * Well, if there are several things about the manual that need fixing:
     219  * why not go through all of it and '''APPLY _ALL_ IMPROVEMENTS NOW''' before the next release?
     220 * If there are going to be several significant changes that could cause confusion (which there are already!),
     221  * let's rather have a big one (cut) instead of continously confusing (cutting) people.
     222
     223----
     224'''init.h grows for synonyms, ugly to look at/ work with.'''
     225
     226 * Include extra file for synonyms (#include synonyms.h). Easy to get rid of once the transition time is declared over.
     227 * They aren't used for anything else and they are not mentionend in the docs, so no loss if sourced out to separate file.
     228
     229----
     230----
     231Can you overcome the (big or not so) implications '''TO YOU ALONE''' accompanying this change this '''_one_ time'''? Please let us know: VarNames/Vote!