Personal tools

IRC channel/Management

From HaskellWiki

< IRC channel(Difference between revisions)
Jump to: navigation, search
(Added Category:Community)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
01:01 +glguy> +mz an wait for a on topic question
+
== Overview ==
01:01 +glguy> all of the offtopic conversations die off
 
01:01 +glguy> because no one can see any responses to them
 
   
01:01 +dons> so the plan should be to ban redirect people into here to talk to them?
+
===Friendliness ===
01:01 +dons> or privmsg, because it's calmer?
 
   
01:02 +glguy> redirect ban to here is good for wide-reaching bans
+
Some people have real issues moderating their behaviour to be friendly or helpful. These are hard cases to deal with, and in the limit can result in permanent bans (some of the #ocaml crowd are haskellers in exile). The usual path is to talk to them, point them to the channel principles, then if they refuse to cooperate, exponentially increasing host bans.
01:02 +glguy> say all of tor
 
01:02 +glguy> or *ass*!*@*
 
01:02 +glguy> where you are likely to have some false positives
 
01:02 +glguy> I don't like them as much for specific bans
 
01:03 +glguy> other uses are redirect bans to ##fix_your_connection
 
01:03 +glguy> where you aren't punishing the person
 
01:03 +glguy> and want them to know that their join/quit flood isn't allowed
 
   
01:04 +glguy> You can "remove"
+
===Redirect bans===
01:04 +glguy> that forces a PART
 
01:04 +glguy> instead of a KICK
 
01:04 +glguy> the difference being that many clients don't auto-rejoin
 
01:04 +glguy> on PART
 
   
01:05 +glguy> +q ____ and +b %____ are identical and just silence the offender
+
Redirect ban to the op channel is good for wide-reaching bans. (e.g.
01:05 +glguy> but don't prevent joins
+
tor or *ass*!*@*), if we expect the odd false positive.
   
01:07 +glguy> oh, and don't forget about +d bans
+
This can also be done for people with problematic connections.
01:07 +glguy> they match on the "real name" field
 
   
==Bans==
+
===Controlling offtopic conversations===
   
I default to *!*@hostname bans, especially when I expect it to be a temporary ban or when banning an unregistered nick. Hostname specific bans against a dynamically assigned hostname should be cleared periodically. -- glguy
+
Never happened in #haskell, but it is possible to manage an off topic
  +
flamefest, with:
   
I am much less lenient with someone that join/spams than with someone that has a history of productive behaviour who slips up. I have no problem kick/temp-banning a join/spammer while I'm likely to warn and chat with a regular user who violates the policy. -- glguy
+
+mz
   
Many users aren't aware of what acceptable #haskell behavior is. We keep the channel noise level low to encourage productive, on-topic discussion. Private messages to a problem user explaining why a behaviour is not acceptable are often successful at neutralizing a situation before it escalates. Of course other users are intentionally disruptive, but even these are eligible to be saved. I will often ban the user in the channel without kicking (which mutes them) and immediately send a private message explaining the situation. --glguy
+
All of the offtopic conversations die off because no one can see any
  +
responses to them.
  +
  +
===Kicks and parts===
  +
  +
You can "remove" that forces a PART instead of a KICK. The difference
  +
being that many clients don't auto-rejoin on PART.
  +
  +
===Silencing===
  +
  +
T +q ____ and +b %____ are identical and just silence the offender but don't prevent joins
  +
  +
===Real name bans===
  +
  +
Some persistent trolls will attempt to rejoin using all available means,
  +
they can be often stopped with realname bans, using +d.
  +
  +
==Policies==
  +
  +
===Bans===
  +
  +
I default to *!*@hostname bans, especially when I expect it to be a
  +
temporary ban or when banning an unregistered nick. Hostname specific
  +
bans against a dynamically assigned hostname should be cleared
  +
periodically.
  +
  +
For example:
  +
  +
/ban *!*@foo.bar.com
  +
  +
I am much less lenient with someone that join/spams than with someone
  +
that has a history of productive behaviour who slips up. I have no
  +
problem kick/temp-banning a join/spammer while I'm likely to warn and
  +
chat with a regular user who violates the policy.
  +
  +
Many users aren't aware of what acceptable #haskell behavior is. We keep
  +
the channel noise level low to encourage productive, on-topic
  +
discussion. Private messages to a problem user explaining why a
  +
behaviour is not acceptable are often successful at neutralizing a
  +
situation before it escalates. Of course other users are intentionally
  +
disruptive, but even these are eligible to be saved. I will often ban
  +
the user in the channel without kicking (which mutes them) and
  +
immediately send a private message explaining the situation.
   
 
==Chaos Control==
 
==Chaos Control==
   
This situation hasn't really happened in #haskell before, but since I've dealt with it in other channels I'll document it here:
+
This situation hasn't really happened in #haskell before, but since I've
  +
dealt with it in other channels I'll document it here:
   
Sometimes the channel can become wildly off-topic with too many people to blame to point individual fingers. The most effective way I've found to deal with this problem is to +o a few of the channel moderators and to set the channel to +mz. This configures the channel such that only +o users can read the messages and respond to them. This off-topic conversation will die out and once someone asks a productive, on-topic questions you can set the mode to -mz and return to normal. -- glguy
+
Sometimes the channel can become wildly off-topic with too many people
  +
to blame to point individual fingers. The most effective way I've found
  +
to deal with this problem is to +o a few of the channel moderators and
  +
to set the channel to +mz. This configures the channel such that only +o
  +
users can read the messages and respond to them. This off-topic
  +
conversation will die out and once someone asks a productive, on-topic
  +
questions you can set the mode to -mz and return to normal. -- glguy
   
 
==Dealing with gateway abuse==
 
==Dealing with gateway abuse==
   
Some people think that IRC gateways like Tor and Mibbit grant them enough anonymity that they can hassle IRC channels unchecked. If someone is reconnecting through such a gateway and proving difficult to ban, do the following (example using tor):
+
Some people think that IRC gateways like Tor and Mibbit grant them
  +
enough anonymity that they can hassle IRC channels unchecked. If someone
  +
is reconnecting through such a gateway and proving difficult to ban, do
  +
the following (example using tor):
  +
  +
/ban *!*@gateway/tor/*!#haskell-ops
  +
  +
This will redirect all Tor users to #haskell-ops. If a legitimate user
  +
gets caught in this wide-reaching ban, you can add an exception for that
  +
specific user:
   
<pre>/ban *!*@gateway/tor/*!#haskell-ops</pre>
+
/mode #haskell +e nick!user@host
   
This will redirect all Tor users to #haskell-ops. If a legitimate user gets caught in this wide-reaching ban, you can add an exception for that specific user:
 
   
<pre>/mode #haskell +e nick!user@host</pre>
+
[[Category:Community]]

Latest revision as of 13:42, 17 December 2012

Contents

[edit] 1 Overview

[edit] 1.1 Friendliness

Some people have real issues moderating their behaviour to be friendly or helpful. These are hard cases to deal with, and in the limit can result in permanent bans (some of the #ocaml crowd are haskellers in exile). The usual path is to talk to them, point them to the channel principles, then if they refuse to cooperate, exponentially increasing host bans.

[edit] 1.2 Redirect bans

Redirect ban to the op channel is good for wide-reaching bans. (e.g. tor or *ass*!*@*), if we expect the odd false positive.

This can also be done for people with problematic connections.

[edit] 1.3 Controlling offtopic conversations

Never happened in #haskell, but it is possible to manage an off topic flamefest, with:

    +mz 

All of the offtopic conversations die off because no one can see any responses to them.

[edit] 1.4 Kicks and parts

You can "remove" that forces a PART instead of a KICK. The difference being that many clients don't auto-rejoin on PART.

[edit] 1.5 Silencing

T +q ____ and +b %____ are identical and just silence the offender but don't prevent joins

[edit] 1.6 Real name bans

Some persistent trolls will attempt to rejoin using all available means, they can be often stopped with realname bans, using +d.

[edit] 2 Policies

[edit] 2.1 Bans

I default to *!*@hostname bans, especially when I expect it to be a temporary ban or when banning an unregistered nick. Hostname specific bans against a dynamically assigned hostname should be cleared periodically.

For example:

   /ban *!*@foo.bar.com

I am much less lenient with someone that join/spams than with someone that has a history of productive behaviour who slips up. I have no problem kick/temp-banning a join/spammer while I'm likely to warn and chat with a regular user who violates the policy.

Many users aren't aware of what acceptable #haskell behavior is. We keep the channel noise level low to encourage productive, on-topic discussion. Private messages to a problem user explaining why a behaviour is not acceptable are often successful at neutralizing a situation before it escalates. Of course other users are intentionally disruptive, but even these are eligible to be saved. I will often ban the user in the channel without kicking (which mutes them) and immediately send a private message explaining the situation.

[edit] 3 Chaos Control

This situation hasn't really happened in #haskell before, but since I've dealt with it in other channels I'll document it here:

Sometimes the channel can become wildly off-topic with too many people to blame to point individual fingers. The most effective way I've found to deal with this problem is to +o a few of the channel moderators and to set the channel to +mz. This configures the channel such that only +o users can read the messages and respond to them. This off-topic conversation will die out and once someone asks a productive, on-topic questions you can set the mode to -mz and return to normal. -- glguy

[edit] 4 Dealing with gateway abuse

Some people think that IRC gateways like Tor and Mibbit grant them enough anonymity that they can hassle IRC channels unchecked. If someone is reconnecting through such a gateway and proving difficult to ban, do the following (example using tor):

   /ban *!*@gateway/tor/*!#haskell-ops

This will redirect all Tor users to #haskell-ops. If a legitimate user gets caught in this wide-reaching ban, you can add an exception for that specific user:

   /mode #haskell +e nick!user@host