This has gone on long enough. I think the initial post was a "let's make people aware of this, in case they aren't already aware of how it works." That has happened. And it worked as intended, there were people who didn't realize how threading worked, and likely some who didn't or don't even know what threading is, but are now curious. Continuing to argue about creating a policy is stupid. We don't need one. But in the same way that telling someone to go f*ck themselves, or posting someone elses home phone number will end with the person recieving a "smarten up" email, usually privately (the first time or two), A friendly little reminder does no harm, and can (as this thread has shown) do some good in terms of education and awareness, which IS the point of this list.
This should be dropped now, because it's making everyone involved (including myself) look like whining little brats. This isn't a big enough issue to merit this many replies. Andrew didn't do anything wrong in suggesting that we do things right, and I don't think he meant to suggest that people should be assassinated for breaking recommended useage rules. People in this group are certainly capable of recognizing new members, and as with everything else, being patient with them as they learn. We've all done things wrong on mailing lists. Sometimes intentionally, that's normal, and fine. But as a rule, we should use tools as they're supposed to be used. It makes us all look professional. This mailing list is a way for people to help each other grow in knowledge and skill. The main guiding policy should be that we will respect and assist others. Kev. On Friday 17 September 2004 04:08, Shawn wrote: > On Friday 17 September 2004 02:33, Andrew J. Kopciuch wrote: > > I don't think that is much of an argument. I would suggest a better > > approach would be to help such users to learn how to properly configure > > said software. Or suggest ways to maintain such addresses (like placing > > them in your contacts). > > > > I don't think encouraging what is deemed as bad behavior, just because > > they don't seem to know how to avoid it is a good idea. Maybe teaching > > them how to avoid that behavior would be better? > > In the business world, you very often receive resistance to these "helpful > suggestions". A good deal of business users don't care about > right/wrong/why in a technical sense - only about how do they get their job > done. Once you've been kicked out of a couple of offices for offering > these "helpful suggestions" or "too much information" you tend to be more > discriminating on when/where you offer them. (for the record, I do believe > in educating my users) > > > > 1. Easier usage for non-technical people. > > > > Why encourage bad habits? That does not help them become more > > technically knowledgeable. > > I can agree with your argument, but putting this into practice isn't going > to be as simple as creating a policy unless the policy is enforced. What's > the punishment for thread hijacking? expulsion from the list? No more > birthday for them? No pudding after dinner? > > > > 2. Increased membership by not requiring members to be technically > > > savvy. > > > > Thread hijacking in no way increases membership. It's a simple action to > > not steal a thread. > > If a member were to be rebuked because they hijacked a thread, but they > were not savvy enough to know they did, and if the rebuke were interpreted > rudely, do you think they would come back? Would they suggest the list to > their friends? If the rebuke was public, isn't there a chance a couple > others would decide to leave? If we develop a bad reputation for being > rude, or scare people away for not being "technical enough", doesn't this > affect membership? You're right, thread hijacking itself doesn't affect > membership. How a policy or guideline on thread hijacking gets enforced > might (or any policy/guidelines for that matter). If the policy isn't > enforced, then why have one? > > > > 3. Increased productivity, by having to do fewer steps to get the job > > > done (i.e send a message to the list) > > > > It's not fewer steps. It's actually more. > > [EMAIL PROTECTED] = 17 keystrokes. More, if someone has to lookup the > address. > Reply (1 click), tab tab delete, tab ctrl-A delete (6 keystrokes - I count > ctrl-A as one keystroke) and one mouse click. > (note, the above excludes any autocomplete features of some email clients) > > > > 4. Friendlier community because people don't get slapped (figuratively) > > > for a minor transgression they may not even be aware of. > > > > You can make them aware and still be friendly. I wouldn't consider a > > great deal of well know communities with similar guidelines as > > "unfriendly". > > This depends highly on the community. So the argument is rather subjective > (IMO). I've been on some lists where you have to be part of the "clique" > before you can get the responses you may need. I've been on others where > any novice error was met with scorn and diresion. I've also been on others > that are very tolerant, and highly successful without explicit policies or > guidelines to cover such issues (like CLUG-Talk). > > > > The choice to use any tool I choose, in any manner I choose. The > > > choice to use a tool to do what I need without having to be an expert > > > on "general accepted behavior". Free as in speech. > > > > I think that's getting out of scope on the topic. The topic was to not > > hijack threads on a mail list. You are free (as in speech), to choose to > > learn the manner in which to do that, with as many tools as are > > available. ;-) > > My comment about choice was a direct response to your question "What choice > are you talking about.". Sure, it may be off topic, but you asked for > clarification. > > > As for your hierarchal argument ... I guess we should remove email > > subjects from the SMTP protocol then? No titles ... just who and when. > > ;-) > > Email subjects are arbitrary. Some of these thread based email clients > group threads by subject (others do it via header values, which gives > better threading support). If a user can arbitrarily change the subject, > the threading gets broken. The threading relies on a hierarchy based on an > arbitrary value. So threading is based on a value that can change at any > time. Therefore threading gets broken, and probably shouldn't be relied on > too heavily. Every email should have a subject that summarizes what the > message is about. Replies to an email should also have a subject, but are > not required to have the same subject, or any subject at all. Your > argument took mine to an unreasonable extreme, or at the very least missed > the context of my comment. > > > It is not thought of ... it is bad form. > > I've already said as much. But I've also said it shouldn't be overly > worried about. > > > So what's the objection to a gentle, polite suggestion in the mail list > > guidelines? You seem to be O.K. with waiting until it happens to let it > > be known as improper, as opposed to prior to the event happening. I > > don't understand why? > > I don't recall rejecting the guideline at all. I'm pretty sure I even said > "Create a guideline or policy if it is felt to be necessary." I just don't > think it's going to do anything to prevent the situation. Honestly, how > often do you read policies? Most people I know ignore the the the pages > containing them. And if someone overly enthusiastic about this were to use > it to correct bad behavior (thread hijacking in this case), I think it will > cause more problems than it prevents (messages potentially being > interpreted as rude and hostile, and the arguments/complaints that > inevitably follow). > > Regardless, as I mentioned in my first message - this is all my own > personal opinion. I am not on the executive, so do not have the authority > to make a decision on this. So it's not me you should be trying to > convince. I've expressed my view, and we've been able to counter each > other's arguments to some degrees. So, if a decision has to be made, the > issue should be fairly well understood by now. > > Shawn > > _______________________________________________ > clug-talk mailing list > [EMAIL PROTECTED] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca _______________________________________________ clug-talk mailing list [EMAIL PROTECTED] http://clug.ca/mailman/listinfo/clug-talk_clug.ca
