channel_guidelines.shtml

<!--#set var="page_title" value="freenode philosophy: channel guidelines" -->
<!--#set var="content_title" value="Channel Guidelines" -->
<!--#include file="include/header-mainlogos.shtml" -->

<p>
  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.
</p>

<p>
  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 be
  designed to require it.  In the low-bandwidth world of IRC, they must get
  emotional feedback via the text they receive.
</p>

<p>
  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."
</p>

<p>
  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
  <span class="freenode">freenode</span> channel guidelines is to avoid
  "feedback loops" in channel interactions by reducing channel temperature.
</p>

<p>
  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 quality of
  your channel.
</p>

<p>
  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.
</p>

<p>
  Guidelines:
</p>

<ul>
  <li>
    <p><b>
      Polish your

      <a href="catalysts.shtml">catalyst</a>

      skills.
    </b>
    
    The catalyst role is key to keeping channel interactions friendly and
    efficient.</p>
  </li>
  
  <li>
    <p><b>Look for the best in people.</b>
    
    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.</p>
  </li>
  
  <li>
    <p><b>Set a good example.</b>
    
    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
    friendy. The habitual behavior of people on a channel is the most
    powerful influence on newbies arriving on the channel.</p>
  </li>

  <li>
    <p><b>
      <a id="messages"></a>Be nice if someone messages you.
    </b>
    
    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.</p>
  </li>

  <li>
    <p><b>
      Don't keep channel operator privileges.
    </b>
      
    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 nick added to the channel access list and op
    yourself only when needed.</p>
  </li>

  <li>
    <p><b>
      Use channel operator privileges sparingly.
    </b>
    
    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.</p>
  </li>

  <li>
    <p><b>
      Avoid highlighting and repetition.
    </b>
    
    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 behaviors irritate people and raise the channel temperature.</p>
  </li>

  <li>
    <p><b>
      Avoid emotive speech.
    </b>
    
    Slang pertaining to sex and sexual orientation, excretion and religious
    oaths is 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.</p>
  </li>
  
  <li>
    <p><b>
      <a id="sensitivematerial"></a>Avoid sensitive material.
    </b>
    
    Some users on
    
    <span class="freenode">freenode</span>
    
    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.</p>

    <p>Additionally, some of our users connect to
    
    <span class="freenode">freenode</span>
    
    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.</p>
  </li>

  <li>
    <p><b>
      Avoid advocacy debates.
    </b>

    BSD versus GPL, vi versus emacs, centralized versus decentralized, 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.</p>

    <p>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.</p>
  </li>

  <li>
    <p><b>
      Take critiques to private message.
    </b>
    
    Criticizing someone's behavior 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
    behavior.  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.</p>
  </li>

  <li>
    <p><b>
      <a id="elitist"></a>Don't be elitist.
    </b>
    
    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? 
    Please think before referring people to links such as

    <a href="http://www.catb.org/~esr/faqs/smart-questions.html">this one</a>,

    which combine suggestions for making support requests with a casual
    attitude of superiority over the newbie.  Helping other people takes
    patience.  It's better not to answer a question than to use the
    opportunity to emphasize the limitations of the person you're trying to
    help.</p>
  </li>

  <li>
    <p><a id="supportburnout"></a><b>Don't be caught by support burnout.</b>
    
    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 <b>support burnout.</b></p>

    <p>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.</p>

    <p>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.</p>

    <p>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).</p>

    <p>Such arbitrary rule sets tend to grow longer over time, because they
    don't solve the real problem.  <b>You can't answer every question, and
    you shouldn't try.</b> 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.</p>
  </li>

  <li>
    <p><b>
      <a id="logging"></a> If you're considering publishing channel logs,
      think it through.
    </b>
    
    The <span class="freenode">freenode</span> network is an interactive
    environment.  Even on public channels, most users don't weigh their
    comments with the idea that they'll be enshrined in perpetuity. For that
    reason, few participants publish logs.</p>
    
    <p>If you're publishing logs on an ongoing basis, your channel topic should
    reflect that fact. Be sure to provide a way for users to make comments
    without logging, and get permission from the channel owners before you
    start.  If you're thinking of "anonymizing" your logs (removing
    information that identifies the specific users), be aware that it's
    difficult to do it well&mdash;replies and general context often provide
    identifying information which is hard to filter.</p>
    
    <p>If you just want to publish a single conversation, be careful to get
    permission from each participant. Provide as much context as you can. 
    Avoid the temptation to publish or distribute logs without permission in
    order to portray someone in a bad light. The reputation you save will
    most likely be your own.</p>
  </li>
</ul>

<!--#set var="SPONSOR_LINKS" value="<small>
        </small>"-->

<!--#include file="include/trailer.shtml" -->