Ah, the sweet munging flam^Wdiscussion. . . begin quoting John H. Robinson, IV as of Wed, Jan 19, 2005 at 02:44:48PM -0800: > Gabriel Sechan wrote: > > >From: "John H. Robinson, IV" <[EMAIL PROTECTED]> > > > > > >Munging *bad* > > > > Munging good. 99.99999% of the time when I reply to a message list post, I > > wish to reply to the list. Thats what reply does with munging. Make the > > common case easy, while not making the uncommon cases impossible.
The assertions being argued are: a) Munging is good b) Uncommon cases aren't impossible > *VERY* common misconception. Most of the time, munging is a no-op, but > let;'s look at the failure cases: > > You reply to a person on a list. This is the 0.00001% case. > Reply-To: shunts that over to the list, > but you intended the person as the recipient. By not paying attention, > and using muscle memory to hit -r- to Reply, you end up going to the > list. Let's remember that we're invoking muscle memory. > On a non-munged list, you hit -r- to Reply to the list, but you fail to > pay attention, and it goes to the individual. Meaning that I start chasing down what's broken with the list, as I don't see my reply show up on the list proper. Effect: a lot of wasted time and effort. > Failure mode for non-munged lists: public information is kept private. > Failure mode for a munged list: private information is made public. However, we've invoked muscle-memory here. That means the most common thing you do will be what you do, regardless. > Ask yourself this, how many times have you seen private information gone > to a public list? I've seen it many times. That's a flaw in the process of double-checking. The problem isn't in the command-set, it is in the process used by the user to review everything before sending. If sensitive information is involved, the user should engage in an extra check of destination, regardless of the actual destination. Misreleasing private information doesn't stop if you change the command set -- you've invoked muscle-memory, after all, which means that people are going to hit what they've trained themselves to hit most often. And that's the key. The special cases should be the special commands; instead of requiring a user to remember that *here* you use -r- to reply, and *there* you use -L- to reply, except that *there* if you want to invoke the special behavior you use -r- instead of -L-. The user has to keep track of *more* state and deal with a complicated (read: esoteric) system in day-to-day use. > There is also the irretrievably lost information associated with > Reply-To's, but since the AOLisation of the internet (a generation I am > a part of, thank you) the Reply-To has more-or-less faded into > obscurity. This is a very minor corner case, granted. It is still there. No information _has_ to be lost. > Non munged lists do not suffer information loss, nor do they have > catastrophic failure modes. I disagree. Non-munged lists suffer from such catastrophic failure modes that I unsubscribe from them rather than put up with it. > Munging makes bad things easy, and makes uncommon things impossible. Not shown. Munging makes the common things easy, which is good, not bad. Not munging makes the common things difficult, which is bad, not good. > Explain how this is better, please. Make sure you address the ``bad > things being easy'' as good and ``uncommon things impossible'' as being > good. Care to first explain how easy things are bad? Or how munging makings some things impossible? > To counter that Reply-To makes common things easy, a good MUA (mutt!) > will differentiate between a group reply, an individual reply, and a > list reply. Not only does it differentiate, it requires the *user* to differentiate. At that point, I might as well use different tools for user to user email and mailing lists. Further, we can then simplify the code for the MUA, getting a more stable, better-targeted, more consistent tool. > Some may argue that an aggregate is the same as a unit, but > I contend that those cannot tell the difference between an apple and a > crate that has apples in it. You can carry an apple. You can carry a crate of apples. Why do we need separate words to describe what is the same action[1]? You reply to a person. You reply to a list. If you are in the context of a list, the idea that you want reply _out_ of band is special. Special actions should require special commands. > Once you have trained your muscles to use L for lists, you rarely make a > mistake between replying to a person, or to a list. Private things are > private, public things are public. This is a good thing. The public/private distinction is illusory, and fostering it is bad. All email should be assumed to be public, as you have no control over who will see it in transit, or who the recipient will show it to. Once you have trained your muscles to use L for lists, you might end up hitting L in non-list contexts, or even hitting L when you meant to hit r for a private response. So the same problem exists, except that day-to-day use requires additional training and practice to avoid doing the unexpected. Of course, all this is moot, because it's all just shortcuts to typing in the destination by hand each time. So the only /true/ solution is to use a MUA that requires you to provide the intended destination each time instead of relying on some heuristic that tries to be "helpful". -Stewart "Still gets caught by tin's crazy f/r distinction" Stremler [1] There are languages like this. They encode the subject or object of an action into the verb; something like there being different words for "bring" -- "<bring [an aggregate]> me [those] apple[s]" versus "<bring [in individual]> me [that] apple". I think it's a bad idea, but not everyone does. Viva la difference, and bring me those apples. -- KPLUG-List mailing list [EMAIL PROTECTED] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
