On Fri, 11 Jul 2003, Jay R. Ashworth wrote: >> The bare fact is, that reply-to munging flamewar threads have >> occured on mailing lists since the first days that reply-to >> munging started happening. I must have been on at least 200 if >> not 500 mailing lists which have had this exact same flamewar, >> and not just once, but several times a year/month, and it creeps >> back up again occasionally. Not just on lists like this one >> which set Reply-to to the list, but also on lists that *dont*, >> where people are arguing that the list *should*. > >I see the former all the time, as to you. > >I've only ever seen the latter, maybe twice in 15 years. > >I'd actually be fairly interested to see the relative percentages.
The overwhelming majority of GNU Mailman lists out there that I've seen, and the majority of other mailing lists I've ever been on - set Reply-To: to point to the list. The lists I am on include the majority of public XFree86.org lists, and the majority of XFree86 related technologies on sourceforge lists such as freetype lists, DRI, Mesa, Glide3, various font and font technology related lists, numerous internal and external Red Hat mailing lists, and lots of other public mailing lists mostly focused on end user help for a given piece of software, or developer lists for such software, including various CVS commits lists. There is one list in about 100 that I am on which does not set Reply-To: to the list, and that is the list for our local Linux users group, of whom the admin is of the same opinion as you, and I munge the headers to have it my way - for me, as I realize flamewars in an attempt to change it is pointless. This is the statistics for _me_ and the lists that I am on. Your statistics, like anyone elses will vary wildly depending on the types of lists that you personally are a member of, and their various policies. The statistics however, are rather irrelevant, because whatever the statistics are, they would be notoriously difficult to obtain and derive useful information from, and mailing lists generally have their own policies for their own reasons, and some random statistical data sampled from a population which is intended to convince a list to change, is not really "unbiased" or neutral. I'm sure nobody wanting a list to change it's policy to THEIR preference, would perform a statistical study, and then show the results to everyone if the numbers did not match their opinion and preference. So statistics are truely meaningless. What is important, is what the list administrator has set for policy, and their indication as to how negotiable this policy is. The majority of lists I've been on, regardless of what their policy is, are typically non-negotiable, and will not change. And that is why people should just agree to disagree and move on. >> Regardless of what *any* one person or 500 people think, this is >> a completely preferential and controversial issue. As >> controversial as abortion, capital punishment, vi vs. emacs, or >> whatever your favourite 50/50 split flamewar is. > >Given safety (which is, admittedly, only an accurate description of the >benefit gained on certain types of mailing lists) versus convenience (which >is how *I* describe making easier for users something their *MUA* should be >making easier for them instead), it seems to be as obvious to me as the >smoking in bars issue -- for the smokers, it's only convenience, they're >gonna die of lung cancer *anyway*... but the non-smokers *weren't*. > >It isn't just the convenience issue the smokers paint it as, and they're >trumped. The list admin is the one you need to convince, and even if he didn't have it decided 100% ago clearly and locked in stone, in addition to convincing him the other way is the correct way and that it should be changed, you'd also have to fight over top of the momentum of the massive majority of people who would complain to no end, and the never ending flamewar that would follow and continue until the list was changed back to it's previous behaviour (yes, about every single time I've seen someone convince a list admin to change this policy, it was changed back within a day or two due to existing longtime subscriber public outcry). You would really need to get 99.9% agreement between all list members (likely over 1000-2000 at a guess) and also the list admins, etc. That is extremely unlikely on this list. >> As such, it is extremely pointless to demand that a given list >> should change it's policy on this issue, regardless of what >> datapoints you'd like to raise. You won't raise even a single >> datapoint that the list maintainers, and the majority of >> subscribers are not already fully 100% aware of. They just >> disagree with you, and are not likely to change their line of >> thinking no matter how much you disagree or how big of a flamewar >> you'd like to make about it. The best you can do, is agree to >> disagree and then move on to another topic - or unsubscribe. > >Pretty sure that I did *not* advocate *this list* changing anything, Mike. > >Go re-check the thread. Was merely expressing an opinion. I don't need to, I know exactly what you said. Expressing your opinion has an undeniable way of suggesting advocation for change to your preference, wether intended or not. Hence why you're receiving the feedback you're getting from various people. >> Regardless of how a particular mailing list is ran with respect >> to Reply-To, _anyone_ who is bothered by a given list's policy, >> can easily change it on their end to suit their own preference. > >Well, not always. *This* list permits user set RT's to go through, but some >lists do *not*, and in that case, your assertion is incorrect. No, my assertion is not correct. Your misunderstanding of my assertion is though, and I wasn't refering to the list's ability to make user supplied RT's continue to work at all. I was refering to your (and my) ability to use procmail or other software to make it work either exactly how either one of us prefers, or fairly close if not perfect, and I never imply that doing so would be 100% perfect. Just that it is a possibility to minimize whatever inconvenience you have rather than leave things 100% inconvenient compared to what your preferences are. >> If you prefer Reply-To to point back to the mailing list, but the >> list does not do that, a simple procmail filter which moves any >> existing Reply-To to Cc, and puts the list address from From: or >> another header into the Reply-To will accomplish that (that's >> what I do). > >Note that the issue here is "what does my message get to *list subscribers* >with a RT set to?" -- an item I *cannot* control if the list doesn't permit >it. > >I don't mind having my opinion ignored on this topic on lists... but let's >all be clear, shall we? To be quite honest, I'm rather surprised nowadays at the relatively SMALL number of people advocating your position on lists that are run contrary to that position. Search through this lists archives and you'll find relatively few people complaining about this. I don't really think anyone owes you a rationale. It's the way it is for good reasons decided upon by the list maintainers which are unlikely to change. As I said last mail, deal with it and move on. Or if you want to know why, then search google and read random flamewars on the topic from any of several hundred thousand publically archived lists. The reasons for it and the reasons against dont ever change, and in the last 7 or more years nobody has come up with more points for or against that hadn't been beaten like a dead horse already. So further discussion is pointless really. >> If you prefer Reply-To: never replying to the list, then have >> procmail strip out the Reply-To: header, and optionally munge >> From: or CC: to Reply-To to simulate putting it back. > >Why would I want to bother? If I could run procmail, I'd just run mutt (or, >likely, one of the KDE mailers which probably also get it right) and not >worry about it. That's your preference. I merely made one suggestion for how you can be empowered to change it for yourself at your own will. There are no doubt other equally good or even better solutions. The point being that while you are not in control of changing the list policies or influencing them likely - you are in control of your own system and how your mail gets munged (if at all) once it gets to your system. And that via munging with software, it is possible to reduce the perceived preferential problem down significantly to where it isn't nearly as bothersome. >> One thing is fairly certain however - you are very unlikely to >> to change long term list policies/preferences to your way of >> doing things via flamewar, and not likely via any other >> mechanism, so just deal with it, or unsubscribe. > >Wasn't staring a flameware, Mike; not real pleased that you're trying to cast >me as *having* tried to start one... I didn't indicate that you started a flamewar. However it is likely that this entire discussion could be classified by you, me, or anyone else listening and/or participating as a flamewar, so it is not an unfair description of the discussion. Not casting blame (and who would really give 2 shits anyway), just describing the flow. >and since the original question was "is there an automated way >to make sure the querent gets an answer" and *I've answered that >twice, with an offer of code and been ignored*, I reserve the >right to be cranky for being bitched at about the issue. I've no quarrel with that. You've got the right to be cranky if you desire. And we've both got the right to share our opinions about the issue(s), and we both have. The point is really that there is no right or wrong. There is different people with different opinions, and an extreme unlikelyhood that everyone can be convinced to see it one way, and even less likely that changes will occur (IMHO). In the event that I am wrong, I have procmail recipes that can change it on my end for myself. Not perfect, but it is good enough for me at least in practice. -- Mike A. Harris _______________________________________________ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
