Re: Q: List Policy
On Saturday 22 November 2008 04:15:42 Henrique de Moraes Holschuh wrote:
> Actually, to be very blunt: CCing people is absolutely the only way to deal
> with massive ammounts of email and very-high-traffic lists when you *care*
> about not ignoring email that you should have read.
That is absolute, 100% pure rubbish. This is solvable by technical means,
right now, today, if email client authors would just implement a feature that
has been standard for decades in forums that far outstrip the volume of
mailing lists, newsgroups. The feature? Scoring.
Even now if you post on a high volume mailing lists there is absolutely no
excuse to miss a message that is posted to it if you're really interested.
Filter....on....References or in-reply-to! Here are the relevant headers
from your message:
References: <[🔎] 200811151343.54157.bss03@volumehost.net>
<[🔎] 491F4761.8030303@cox.net> <[🔎] 491F8FD1.1060904@allums.com>
<[🔎] 491F915E.5000807@cox.net> <[🔎] 491FBDEC.9030604@allums.com>
<[🔎] 20081117100303.GD7280@localhost.localdomain> <4921607E.8030500@physik.blm.tu-
In-Reply-To: <[🔎] 4927F088.4020103@dmiyu.org>
Since, at least in KMail, I can set any prefix in my MSGID I put a static
string there then filter on an In-Reply-To that starts with that string and
ends with "@dmiyu.org", highlight it, filter it into a different folder,
whatever. I don't miss mail and I don't require a harmful, blanket policy
that annoys many people and wastes resources.
> If you want an example of a CC policy radically different from Debian's,
> take a look at the development mailinglists for the Linux kernel and all
> related projects. There, the policy is that you are to *always* CC
> everyone that should (or might even remotely need to) get an email, in
> addition to sending it to the lists. Otherwise, the chances that such an
> email will be lost in the ocean of stuff, or never reach the right people.
To be blunt, if those people can't figure out how to filter on In-Reply-To
they have no business hacking the kernel.
> IMO the truth behind the CC policy in Debian lists is that it is the policy
> not to do so for a LONG time now, and a lot of people is bothered by CCs,
> so they resist any such changes (note: I am NOT judging whether they're
> right or wrong for doing that, if one could even classify such an issue in
> that way).
Sorry, but it is a sane method of doing so. Quite frankly if I put inject
something into a conversation and it later turns a different direction that
doesn't interest me I can simply stop reading those messages. Or, to put it
another way, you can unsubscribe from a list. You can't unsubscribe from a CC
list.
> IMO, the reason many people are bothered by the CCs is that the
> typical DM, DD and Debian user just plain don't *care* about stuff from
> debian-user/-policy/-private/* bothering him all the time. He'd rather
> ignore it completely until he decides to read that ML folder, if ever.
I'm pretty sure you're wrong on that.
> In the end, it boils down to the fact that most people have lame mail
> filtering setups that cannot sort delivery mailboxes in the right priority
> and do proper destination-based duplicate supression (so that you can get
> automated "if it is also destined to a Debian ML, file into the ML folder,
> and have any further duplicates supressed), and are not in any hurry to
> deploy one.
Uh-huh. If that's the case then why CC? Sorry, there is absolutely 0
cases where CCing when unrequested is appropriate. Your volume argument is
complete rubbish. Forcing people to filter because of other people's
inconvenient poor habits is akin to the harm done by C-R. Finally, don't
think I don't get the cute idea of you CCing me this message. I am not
amused, don't do it again. I have never ask for a CC from this list and never
will. To CC me against the list's CoC clearly shows you're more interesting
in trolling than contributing anything meaningful to the conversation.
--
Steve C. Lamb | But who can decide what they dream
PGP Key: 1FC01004 | and dream I do
-------------------------------+---------------------------------------------
Reply to: