Personal tools

IRC channel/Management

From HaskellWiki

< IRC channel(Difference between revisions)
Jump to: navigation, search
Line 32: Line 32:
   
 
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
 
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

Revision as of 20:29, 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