[nSLUG] Please do not use Reply for new topics

Daniel Morrison draker at gmail.com
Fri Oct 9 12:30:53 ADT 2009

Thanks for both your answers. It's funny, I didn't really think about
these for email, only for usenet.

2009/10/9 Stephen Gregory <nslug at kernelpanic.ca>:
> On Fri, Oct 09, 2009 at 11:56:38AM -0300, Daniel Morrison wrote:

>> Some invention
>> that was intended to "make life easier" by allowing threads to
>> continue over subject changes, but which is instead now imposing more
>> rules on members?
> Watch it there young whipper-snapper. :-)
> This style of threading has been a standard (of sorts) since
> RFC822. It was written in 1982.

I suppose the situation must have improved since this was written, in 1999:

"most email programs do not support In-Reply-To headers"

But it still leaves me wonder why the threading software has made the
decision that these headers are more important than the subject. Is it
really more common for a conversation to change subject than for the
subject change to mark the start of a (completely unrelated) subject?
Or maybe a better question would be: shouldn't new subjects signal the
start of a new "subject thread" anyway?

I am drifting into virtual territory, which does not change the
reality of our list, so I guess at this time it is important to *not*
reply to unrelated messages.

Still, while I'm dreaming away... it would be nice for email clients
to have a 'reset/purge references' button, to allow control of this
feature. I really think the computers should mold themselves to human
behaviour as much as possible, rather than the other way around. Try
telling my parent's generation that "you're doing it wrong" when as
far as they know it's been working just fine all this time...

I know, mail clients could wait until the subject line is changed,
then pop-up a message:
"You're changing the subject. Is this the start of a new, unrelated
topic? [Yes/purge threads] [No/keep threads]"

BTW I found a good summary here: http://cr.yp.to/immhf/thread.html



More information about the nSLUG mailing list