Difference between revisions of "IRC channel/Management"
Line 34: | Line 34: | ||
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 |
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 |
||
+ | |||
+ | ==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 |
Revision as of 20:34, 18 August 2008
01:01 +glguy> +mz an wait for a on topic question 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? 01:01 +dons> or privmsg, because it's calmer?
01:02 +glguy> redirect ban to here is good for wide-reaching 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" 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 01:05 +glguy> but don't prevent joins
01:07 +glguy> oh, and don't forget about +d bans 01:07 +glguy> they match on the "real name" field
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. -- glguy
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
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
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