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

[mr.Natural]

A very big +1

Please grow up 'collective intelligence PP'.

When said "you are full of shit", although rude/primitive, is just another way of expressing an opinion. What is so wrong about "a sac a foutre" in French ? Not proper French ? My ass. :-) 

MrNatural.

rencontres <rencontres3 at gmail.com> wrote:
>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.
>_______________________________________________
>Discussions mailing list
>Discussions at lists.partipirate.org
>http://lists.partipirate.org/mailman/listinfo/discussions

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.partipirate.org/pipermail/discussions/attachments/20130903/0b2d6cdb/attachment.html>