[PP-discussions] modes d'echanges... en irc et ailleurs... [en] catalyst 'wanted'

[rencontres]

apres une semaine un peu mouvementée envie de remettre sur le tapis
qques idées simples...

et en deuxieme partie...
queqlues mots ou nous pourrions remplacer aisement frenode par pp!
catalysts wanted! ...

------------
as said by our friends... comme raconté par nos amis... de freenode...
les echanges via clavier/ecrans......are  low-bandwidth methods 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 be designed to require it. In the
low-bandwidth world of IRC, they must get emotional feedback via 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
quality of your channel.

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 key 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 friendy. The habitual behavior 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 keep 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 nick
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
behaviors irritate people and raise the channel temperature.

Avoid emotive speech. 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.

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, 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.

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 critiques to private message. 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.

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? Please think before referring people
to links such as this one, 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.

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

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—replies and general context often
provide identifying information which is hard to filter.

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.

=================
Catalysts

The "catalyst" role is critical to freenode and an essential building
block of channels. No one is required to be a catalyst, but the users
who perform this role ensure the smooth and efficient functioning of
the network.

IRC does not automatically produce a stable culture of cooperative
effort. Even in cases where cooperation is intended, misunderstandings
and personality incompatibilities can result in an extremely chaotic
and hostile environment. Catalysts help prevent and resolve
misunderstanding, calm the waters when users have difficulties dealing
with each other and provide examples of constructive behavior in
environments where such behavior might not otherwise be the norm.

Catalysts try to resolve problems, not through the use of authority
and special privilege, but by fostering consensus, gently nudging
participants in the direction of more appropriate behavior and by
generally reducing the level of confrontation rather than confronting
users with problems.

Channel and network administrators may be catalysts and, indeed, are
encouraged to take on that role. Channels which recognize the
importance of the catalyst role will foster more effective
coordination of effort. An important characteristic of successful
catalysts is the infrequency with which they wear authority or invoke
special privilege.

freenode staffers and facilities hosting personnel are advised that an
understanding and appreciation of the role of catalyst is essential to
understanding the nature and intended purpose of the network. As the
network grows in size, formal training in the catalyst role will be
provided.

An effective catalyst is:

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.

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.

Responsible. Peer-directed projects are a group activity with a strong
need for responsible individual behavior. Rumors, 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?

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 critique the user if
a quiet change of subject, or a private conversation on a completely
different topic, can help make the problem fade away.

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.

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.

Attentive. Understand the situation you have walked into before you
act. Question your assumptions. Look for signs you have misinterpreted
the situation, in order to avoid causing difficulties for a user who
did not create the problem.

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.

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.

Cooperative. Look for opportunities to get people involved in the
resolution of their own and others' problems.

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.

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.