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
