freenode volunteers and sponsors are advised that an understanding and appreciation of the catalyst’s role is essential to understanding the nature and intended purpose of the network..
### An effective catalyst is:
-1. **Relaxed.** To keep things calm, you yourself must be calm. Learn the skills of staying genuinely relaxed. Know your limitations; when you can't handle a problem situation calmly, get calmer heads involved.
-2. **Open-minded.** It's easy to make assumptions about other people's motivations. When you decide someone is behaving maliciously, you've made an assumption about their motivation which may be difficult to disprove. Try to make your assumptions about other people's motivations as positive as possible.
-3. **Responsible.** Peer-directed projects are a group activity with a strong need for responsible individual behaviour. Rumours, innuendo and gossip can derail projects and ruin reputations. If everybody knows something is true, who is "everybody?" Did the person you're talking to get their information from documented, factual sources, or is it hearsay? If you can't be sure of the answer to those questions, should you be passing on what they've said?
-4. **Unobtrusive.** It's not necessary to invoke authority to help solve a problem, and far better if you don't. Look for an opportunity to nudge the situation into a more productive track. Don't criticise the user if a quiet change of subject, or a private conversation on a completely different topic, can help make the problem fade away.
-5. **Realistic.** Accept the personalities of your users and concentrate on problem resolution. Don't expect people to suddenly change their personalities to make problem resolution easier.
-6. **Careful.** Everything you say will be interpreted by the users with whom you interact. Consider how your remarks will be interpreted before you make them. Make sure the message you convey is the one you intend.
-7. **Attentive.** Understand the situation you have walked into before you act. Question your assumptions. Look for signs that you may have misinterpreted the situation, in order to avoid causing difficulties for a user who did not create the problem.
-8. **Minimalist.** Don't do more than you need to in order to resolve a problem. A problem scene is often the wrong time and place to set policy. Concentrate on the resolution, and on collecting information you can think about later.
-9. **Courteous.** Even under time pressure, courtesy costs little and impresses people a lot. It's not about whether working with the person is easy or difficult; it's about setting the right tone.
-10. **Cooperative.** Look for opportunities to get people involved in the resolution of their own and others' problems.
-11. **Someone with an internal locus of control.** Catalysts concentrate on solving problems, not bestowing blame. Treat the situation as the problem, accept the users for who they are and try to figure out how best to help resolve the difficulty.
-12. **A user.** Remember that you're not in charge. Everybody runs their own little corner of the world. Let them do the job they're capable of. Just help the process along as unobtrusively as possible. Other catalysts are users as well, and nobody is perfect.
-
+1. **Relaxed.** To keep things calm, you yourself must be calm. Learn the skills of staying genuinely relaxed. Know your limitations; when you can't handle a problem situation calmly, get calmer heads involved.
+2. **Open-minded.** It's easy to make assumptions about other people's motivations. When you decide someone is behaving maliciously, you've made an assumption about their motivation which may be difficult to disprove. Try to make your assumptions about other people's motivations as positive as possible.
+3. **Responsible.** Peer-directed projects are a group activity with a strong need for responsible individual behaviour. Rumours, innuendo and gossip can derail projects and ruin reputations. If everybody knows something is true, who is "everybody?" Did the person you're talking to get their information from documented, factual sources, or is it hearsay? If you can't be sure of the answer to those questions, should you be passing on what they've said?
+4. **Unobtrusive.** It's not necessary to invoke authority to help solve a problem, and far better if you don't. Look for an opportunity to nudge the situation into a more productive track. Don't criticise the user if a quiet change of subject, or a private conversation on a completely different topic, can help make the problem fade away.
+5. **Realistic.** Accept the personalities of your users and concentrate on problem resolution. Don't expect people to suddenly change their personalities to make problem resolution easier.
+6. **Careful.** Everything you say will be interpreted by the users with whom you interact. Consider how your remarks will be interpreted before you make them. Make sure the message you convey is the one you intend.
+7. **Attentive.** Understand the situation you have walked into before you act. Question your assumptions. Look for signs that you may have misinterpreted the situation, in order to avoid causing difficulties for a user who did not create the problem.
+8. **Minimalist.** Don't do more than you need to in order to resolve a problem. A problem scene is often the wrong time and place to set policy. Concentrate on the resolution, and on collecting information you can think about later.
+9. **Courteous.** Even under time pressure, courtesy costs little and impresses people a lot. It's not about whether working with the person is easy or difficult; it's about setting the right tone.
+10. **Cooperative.** Look for opportunities to get people involved in the resolution of their own and others' problems.
+11. **Someone with an internal locus of control.** Catalysts concentrate on solving problems, not bestowing blame. Treat the situation as the problem, accept the users for who they are and try to figure out how best to help resolve the difficulty.
+12. **A user.** Remember that you're not in charge. Everybody runs their own little corner of the world. Let them do the job they're capable of. Just help the process along as unobtrusively as possible. Other catalysts are users as well, and nobody is perfect.
+
We're all just here to do our best to keep things running well.
Title: Channel Guidelines
---
### Channel Guidelines
-IRC is a low-bandwidth method of communication, in comparison with physical presence. Many of the cues of physical communication, tone of voice, facial expression, hand movements, etc., are missing in IRC, since only text is transmitted back and forth.
-Speakers in physical proximity with each other communicate quite a bit of emotional context via this extra bandwidth. This context enables them to avoid misjudging the intent of their conversational partners. It also functions as an unconscious negative feedback mechanism to reduce the incidence of emotional "firestorms" which tend to disrupt the efficient flow of conversation. Human beings look for this feedback, and indeed they may have evolved to require it. In the low-bandwidth world of IRC, they must instead rely on emotional feedback from the text they receive.
-
-This process is subject to exaggeration. Small amounts of emotion become magnified in the perception of the observer. So, it is very important to keep channels calm. An informal conceptual measurement of the emotional content of a channel is its "channel temperature."
-
-Think of a person's emotional state as kinetic energy. Enthusiasm, happiness, anger, frustration all add to the energy level. The more emotion is experienced, the "hotter" the participant. The average emotional state of a channel is its temperature. Emotions in IRC become exaggerated and conveying them directly increases channel temperature. Pent-up frustration, in particular, is often released as a series of inappropriate, "high energy" outbursts. An important objective of the freenode channel guidelines is to avoid "feedback loops" in channel interactions by reducing channel temperature.
-
-The guidelines which follow are designed with the benefit of years of experience with IRC, beginning during the 1993-1994 period when the design limitations of IRC began to become clear due to the increasing scale of IRC networks. Adopting the guidelines will help improve the overall quality of your channel, and of the discussions that can take place in it.
-We intentionally avoid drawing a distinction between channel operators and users. Everyone is a user, regardless of their privilege level, and each user has the ability to influence the usability of the channel.
-
-####Guidelines:
-- **Polish your catalyst skills.** The catalyst role is crucial to keeping channel interactions friendly and efficient.
-- **Look for the best in people.** If you assume people have no self-control, they'll confirm your belief. If you look for personal responsibility, and ask for personal responsibility, most people will respond well.
-- **Set a good example.** Be what you want other people to be. If you want them to be calm, be calm. If you want them to be courteous and friendly, be courteous and friendly. The habitual behaviour of people on a channel is the most powerful influence on newbies arriving on the channel.
-- **Be nice if someone messages you.** They've gone to the trouble to seek out someone with the background to help them. You're it! Be flattered they've singled you out. If you think they'll get better support by asking their question on channel, just let them know.
-- **Don't display channel operator privileges.** Displaying these privileges on your nick with a "+o" attracts participants who are interested in gaining them and using them actively; it also attracts the attention of participants who react negatively to authority. Have your account added to the channel access list and op yourself only when needed.
-- **Use channel operator privileges sparingly.** Each time you use them you raise the channel temperature. Users will be pleased with you, angry at you, frustrated that you used them inappropriately, envious that you have control over the discussion. None of these reactions may be conscious on the part of other users, but all of them increase the channel temperature.
-- **Avoid highlighting and repetition.** Words and sentences in all-uppercase, heavy use of highlighting, beeping (^G) on public channels, repeating the same lines over and over--all of these behaviours irritate people and raise the channel temperature.
-- **Avoid emotive speech.** Slang pertaining to sex and sexual orientation, excretion and religious oaths are rarely used to discuss the applicability of those topics to your group's activities. In general, language with strong emotional content and only light meaning should be considered "emotive speech". It doesn't matter whether the language is socially acceptable or unacceptable. For example, use of the word "fsck" which does not refer to a Unix filesystem check is emotive. Similarly, use of the word "gay" which has nothing to do with homosexuality is emotive. Emotive speech raises the channel temperature.
-- **Avoid sensitive material.** Some users on freenode channels, particularly on public channels, are quite young. Others are parents or teachers who might have young children nearby. As you type comments or ASCII art, or post URLs for others to view, please consider the age range of other users on your channel, and respect the right of parents and teachers to decide when and if to expose the children in their charge to material or language which might offend, confuse or raise difficult issues.
-
-Additionally, some of our users connect to freenode from corporate environments. Employers may be unhappy with the unexpected appearance of sensitive material on workplace computers. Please be considerate and avoid posting such material when you're not completely sure it's safe to do so.
-
-- **Avoid advocacy debates.** BSD versus GPL, vi versus emacs, centralised versus decentralised, RMS versus ESR: these discussions are frequently religious and may not involve significant new ideas. They can also raise the channel temperature quite a bit. Certain advocacy discussions, such as those revolving around actual religion or politics, are almost guaranteed to raise the channel temperature to levels that make other conversation difficult.
-
-You might not get too worked up if you're arguing the relative merits of poll() or kqueue(), but if you walk into a discussion with a strong emotional need to "get your way," consider the possibility you are simply arguing preference or personal affiliation. Advocacy discussions are best held quietly, via /msg, or on channels especially created for the purpose.
-- **Take criticism to private message.** Criticising someone's behaviour on channel holds them up to public scrutiny in a negative way. It's usually overkill. In your messages, don't address the subject of whether you have channel operator privileges; just be courteous. Request nicely that they change their behaviour. In many cases you'll discover that problem user you are dealing with is merely inexperienced. An aggressive tone makes for a longer and more involved discussion, and pent-up frustration which will raise the channel temperature sooner or later. You can always use channel operator privileges, or have someone else use them, as needed; but with a courteous tone, you'll need to do that a lot less.
-- **Don't be elitist.** Today's newbies are tomorrow's experts. A support channel is a place where people with knowledge lead by example. Is the example you want to set that technical knowledge is a hierarchy of control, or that people with knowledge have an inherent social advantage over people who don't? Helping other people takes patience. It's better not to answer a question than to use the opportunity to emphasise the limitations of the person you're trying to help.
-- **Don't be caught by support burnout.** It's nearly impossible to answer every technical question that comes to your channel. In many cases, the problem doesn't lie in the technical aspects of the question; cultural barriers may get in the way of communication, or it may be difficult to explain to a newbie just where to begin. When you try to answer every question, regardless of difficulty, you set yourself up for **support burnout**.
-
-Support burnout is nearly always accompanied by the feeling that you're losing control of your time, that the people you've set out to help are making unreasonable demands. The problem is that you're taking on too much responsibility; but it begins to appear instead that the problem is the end user who's asking for help.
-Different people react to support burnout in different ways. Some offer malicious advice ("rm -rf /" etc.) to newbies. Some insist that every question a newbie asks should be answered with a URL or by lists of manual references.
-When the staff of a support channel suffer from support burnout, they're likely to set arbitrary rules for participation; these might include prohibiting the use of certain phrases in channel, or disallowing the use of private messages to contact channel members. Staff might promulgate a lengthy, multi-page rules document ending with a special procedure the user must employ to be voiced in the channel (to make sure they've read the entire document before asking any questions).
-Such arbitrary rule sets tend to grow longer over time, because they don't solve the real problem. **You can't answer every question, and you shouldn't try.** Be gentle, be courteous, be flexible and be as patient and helpful as you can---but let someone else try to answer questions that you find too frustrating. Don't try to be a superhuman support machine.
-- **If you're considering publishing channel logs**, think it through. The freenode network is an interactive, real-time environment where discussions may be heavily influenced by external context. Even on public channels, most users don't weigh their comments with the idea that they'll be enshrined in perpetuity to stand on their own. For that reason, few participants publish logs and we encourage those communities that do to make their participants aware of this fact.
+IRC is a low-bandwidth method of communication, in comparison with physical presence. Many of the cues of physical communication, tone of voice, facial expression, hand movements, etc., are missing in IRC, since only text is transmitted back and forth.
+Speakers in physical proximity with each other communicate quite a bit of emotional context via this extra bandwidth. This context enables them to avoid misjudging the intent of their conversational partners. It also functions as an unconscious negative feedback mechanism to reduce the incidence of emotional "firestorms" which tend to disrupt the efficient flow of conversation. Human beings look for this feedback, and indeed they may have evolved to require it. In the low-bandwidth world of IRC, they must instead rely on emotional feedback from the text they receive.
+
+This process is subject to exaggeration. Small amounts of emotion become magnified in the perception of the observer. So, it is very important to keep channels calm. An informal conceptual measurement of the emotional content of a channel is its "channel temperature."
+
+Think of a person's emotional state as kinetic energy. Enthusiasm, happiness, anger, frustration all add to the energy level. The more emotion is experienced, the "hotter" the participant. The average emotional state of a channel is its temperature. Emotions in IRC become exaggerated and conveying them directly increases channel temperature. Pent-up frustration, in particular, is often released as a series of inappropriate, "high energy" outbursts. An important objective of the freenode channel guidelines is to avoid "feedback loops" in channel interactions by reducing channel temperature.
+
+The guidelines which follow are designed with the benefit of years of experience with IRC, beginning during the 1993-1994 period when the design limitations of IRC began to become clear due to the increasing scale of IRC networks. Adopting the guidelines will help improve the overall quality of your channel, and of the discussions that can take place in it.
+We intentionally avoid drawing a distinction between channel operators and users. Everyone is a user, regardless of their privilege level, and each user has the ability to influence the usability of the channel.
+
+####Guidelines:
+- **Polish your catalyst skills.** The catalyst role is crucial to keeping channel interactions friendly and efficient.
+- **Look for the best in people.** If you assume people have no self-control, they'll confirm your belief. If you look for personal responsibility, and ask for personal responsibility, most people will respond well.
+- **Set a good example.** Be what you want other people to be. If you want them to be calm, be calm. If you want them to be courteous and friendly, be courteous and friendly. The habitual behaviour of people on a channel is the most powerful influence on newbies arriving on the channel.
+- **Be nice if someone messages you.** They've gone to the trouble to seek out someone with the background to help them. You're it! Be flattered they've singled you out. If you think they'll get better support by asking their question on channel, just let them know.
+- **Don't display channel operator privileges.** Displaying these privileges on your nick with a "+o" attracts participants who are interested in gaining them and using them actively; it also attracts the attention of participants who react negatively to authority. Have your account added to the channel access list and op yourself only when needed.
+- **Use channel operator privileges sparingly.** Each time you use them you raise the channel temperature. Users will be pleased with you, angry at you, frustrated that you used them inappropriately, envious that you have control over the discussion. None of these reactions may be conscious on the part of other users, but all of them increase the channel temperature.
+- **Avoid highlighting and repetition.** Words and sentences in all-uppercase, heavy use of highlighting, beeping (^G) on public channels, repeating the same lines over and over--all of these behaviours irritate people and raise the channel temperature.
+- **Avoid emotive speech.** Slang pertaining to sex and sexual orientation, excretion and religious oaths are rarely used to discuss the applicability of those topics to your group's activities. In general, language with strong emotional content and only light meaning should be considered "emotive speech". It doesn't matter whether the language is socially acceptable or unacceptable. For example, use of the word "fsck" which does not refer to a Unix filesystem check is emotive. Similarly, use of the word "gay" which has nothing to do with homosexuality is emotive. Emotive speech raises the channel temperature.
+- **Avoid sensitive material.** Some users on freenode channels, particularly on public channels, are quite young. Others are parents or teachers who might have young children nearby. As you type comments or ASCII art, or post URLs for others to view, please consider the age range of other users on your channel, and respect the right of parents and teachers to decide when and if to expose the children in their charge to material or language which might offend, confuse or raise difficult issues.
+ Additionally, some of our users connect to freenode from corporate environments. Employers may be unhappy with the unexpected appearance of sensitive material on workplace computers. Please be considerate and avoid posting such material when you're not completely sure it's safe to do so.
+- **Avoid advocacy debates.** BSD versus GPL, vi versus emacs, centralised versus decentralised, RMS versus ESR: these discussions are frequently religious and may not involve significant new ideas. They can also raise the channel temperature quite a bit. Certain advocacy discussions, such as those revolving around actual religion or politics, are almost guaranteed to raise the channel temperature to levels that make other conversation difficult.
+ You might not get too worked up if you're arguing the relative merits of poll() or kqueue(), but if you walk into a discussion with a strong emotional need to "get your way," consider the possibility you are simply arguing preference or personal affiliation. Advocacy discussions are best held quietly, via /msg, or on channels especially created for the purpose.
+- **Take criticism to private message.** Criticising someone's behaviour on channel holds them up to public scrutiny in a negative way. It's usually overkill. In your messages, don't address the subject of whether you have channel operator privileges; just be courteous. Request nicely that they change their behaviour. In many cases you'll discover that problem user you are dealing with is merely inexperienced. An aggressive tone makes for a longer and more involved discussion, and pent-up frustration which will raise the channel temperature sooner or later. You can always use channel operator privileges, or have someone else use them, as needed; but with a courteous tone, you'll need to do that a lot less.
+- **Don't be elitist.** Today's newbies are tomorrow's experts. A support channel is a place where people with knowledge lead by example. Is the example you want to set that technical knowledge is a hierarchy of control, or that people with knowledge have an inherent social advantage over people who don't? Helping other people takes patience. It's better not to answer a question than to use the opportunity to emphasise the limitations of the person you're trying to help.
+- **Don't be caught by support burnout.** It's nearly impossible to answer every technical question that comes to your channel. In many cases, the problem doesn't lie in the technical aspects of the question; cultural barriers may get in the way of communication, or it may be difficult to explain to a newbie just where to begin. When you try to answer every question, regardless of difficulty, you set yourself up for **support burnout**.
+ Support burnout is nearly always accompanied by the feeling that you're losing control of your time, that the people you've set out to help are making unreasonable demands. The problem is that you're taking on too much responsibility; but it begins to appear instead that the problem is the end user who's asking for help.
+ Different people react to support burnout in different ways. Some offer malicious advice ("rm -rf /" etc.) to newbies. Some insist that every question a newbie asks should be answered with a URL or by lists of manual references.
+ When the staff of a support channel suffer from support burnout, they're likely to set arbitrary rules for participation; these might include prohibiting the use of certain phrases in channel, or disallowing the use of private messages to contact channel members. Staff might promulgate a lengthy, multi-page rules document ending with a special procedure the user must employ to be voiced in the channel (to make sure they've read the entire document before asking any questions).
+ Such arbitrary rule sets tend to grow longer over time, because they don't solve the real problem. **You can't answer every question, and you shouldn't try.** Be gentle, be courteous, be flexible and be as patient and helpful as you can---but let someone else try to answer questions that you find too frustrating. Don't try to be a superhuman support machine.
+- **If you're considering publishing channel logs**, think it through. The freenode network is an interactive, real-time environment where discussions may be heavily influenced by external context. Even on public channels, most users don't weigh their comments with the idea that they'll be enshrined in perpetuity to stand on their own. For that reason, few participants publish logs and we encourage those communities that do to make their participants aware of this fact.
There are several elements to the freenode philosophy. The project was originally founded to provide interactive discussion facilities to **peer-directed project communities**. Peer-directed projects combine open, informal participation with broad licensing and wide dissemination of output.
Our basic principles are:
- - **Community members benefit from better access to each other.** Putting a number of projects in close proximity in an interactive environment creates linkages between developers and projects, and helps community members take better advantage of each other's work.
- - **Communication and coordination skills are important to community projects.** Peer-directed projects work because the paradigm works. Developers and community members are not unusually gifted at project coordination and communication. But improving those skills can make projects work better.
- - **Friendly interaction is more efficient than flaming.** Calm, relaxed discourse without angry contention provides for better exchange of information. Flaming produces situations in which the listener must contend with the state of his or her emotions at least as much as with the comprehension of a speaker's comments.
- - **Project developers are self-driven.** No one guarantees your work will be used, but only you decide whether a project is worth doing. There is no single right approach to any design, implementation or support problem, and friendly competition is a fundamentally good thing.
- - **Peer-directed project communities need to grow.** Many valuable peer-directed projects chronically lack skilled, motivated developers with time to devote to them. The potential base for peer-directed project communities includes anyone with the skills and interest to participate. These communities must continue to grow.
- - **Licensing must be free.** For peer-directed projects to succeed, their creative output must be widely available and usable without significant restriction. For software projects, the [Debian Free Software Guidelines](http://www.debian.org/social_contract#guidelines), the Free Software Foundation's [Free Software Definition](http://www.gnu.org/philosophy/free-sw.html) and the Open Source Initiative's [Open Source Definition](http://www.opensource.org/docs/definition.php) provide guidelines to help ensure that project creative output remains free. For artistic projects and for the printed word, licenses provided by [Creative Commons](http://creativecommons.org/licenses/) and efforts such as the [GNU Free Documentation License](http://www.gnu.org/licenses/fdl.html) and the [FreeBSD Documentation License](http://www.freebsd.org/copyright/freebsd-doc-license.html) help keep creative output free.
-
-Licensing which preserves the ability of newcomers to contribute, and maintains a low barrier to entry for development, is essential to the health and success of peer-directed projects.
+
+ - **Community members benefit from better access to each other.** Putting a number of projects in close proximity in an interactive environment creates linkages between developers and projects, and helps community members take better advantage of each other's work.
+ - **Communication and coordination skills are important to community projects.** Peer-directed projects work because the paradigm works. Developers and community members are not unusually gifted at project coordination and communication. But improving those skills can make projects work better.
+ - **Friendly interaction is more efficient than flaming.** Calm, relaxed discourse without angry contention provides for better exchange of information. Flaming produces situations in which the listener must contend with the state of his or her emotions at least as much as with the comprehension of a speaker's comments.
+ - **Project developers are self-driven.** No one guarantees your work will be used, but only you decide whether a project is worth doing. There is no single right approach to any design, implementation or support problem, and friendly competition is a fundamentally good thing.
+ - **Peer-directed project communities need to grow.** Many valuable peer-directed projects chronically lack skilled, motivated developers with time to devote to them. The potential base for peer-directed project communities includes anyone with the skills and interest to participate. These communities must continue to grow.
+ - **Licensing must be free.** For peer-directed projects to succeed, their creative output must be widely available and usable without significant restriction. For software projects, the [Debian Free Software Guidelines](http://www.debian.org/social_contract#guidelines), the Free Software Foundation's [Free Software Definition](http://www.gnu.org/philosophy/free-sw.html) and the Open Source Initiative's [Open Source Definition](http://www.opensource.org/docs/definition.php) provide guidelines to help ensure that project creative output remains free. For artistic projects and for the printed word, licenses provided by [Creative Commons](http://creativecommons.org/licenses/) and efforts such as the [GNU Free Documentation License](http://www.gnu.org/licenses/fdl.html) and the [FreeBSD Documentation License](http://www.freebsd.org/copyright/freebsd-doc-license.html) help keep creative output free.
+
+Licensing which preserves the ability of newcomers to contribute, and maintains a low barrier to entry for development, is essential to the health and success of peer-directed projects.
projects / irc / freenode / web-7.0.git / commitdiff
