IRC オペレータ ガイドライン
Here are some points to remember when enabling operator status:
- Stay friendly: Trolls, flooders, people with no social skills–they all
visit from time to time. If someone is abusive, warn him or her. If someone won’t
learn or gets aggressive, remove the offender from the chat. If someone is
(accidentally) flooding, mute or remove that person and give the URL to our
pastebin. Don’t forget to unmute when you think the flood is over. Never
swear at people, though; always stay friendly. If you remove a very abusive
person, don’t respond to the cheering you will get. Don’t be surprised at the
abuse and swearing in private messages you will get either.
- Don’t hold ops: After you finish doing what you needed operator privileges for,
de-op yourself. Staying +o for long periods is not really useful and you’ll
attract unneeded attention. A possible exception is when general commotion
might be going on in the channel and staying +o might be useful to indicate
to other members that you are around, so that they don’t need to call !ops.
- Don’t use ignore: Even when people are very offensive to you in private
chat, don’t use your /ignore function. A soft-ignore (simply not
responding) works nearly as well. If you /ignore too much, chances are you
will miss problems in the channel. Freenode also has +g user mode, which
blocks private messages and notices but not channel activity. If someone is
abusive in private, /mode <your_nick> +g can help; you can add exceptions with
/accept command. Do not filter your channel info (joins/parts/klines etc).
These also hold much info.
- Ban on sight: So far there have been no very abusive users. In extreme
cases, users can be added to a special list in ChanServ that prevents them from
ever entering the channel again. If you think someone qualifies for this list,
discuss it with the other operators in #nginx-master.
- Clean your bans regularly: It is unavoidable that people will be banned.
Make sure you don’t simply forget these bans and never remove them. Users
usually learn from their mistakes, and very often a long term ban is not
needed. The IRC bot is a useful tool to review why a ban was put in place.
- Comment on your bans: ngxbot logs all kicks/bans/removes/mutes. You can
comment on your actions in the ban tracker. This is really useful to keep
track of both abusive users and bans that are around for a long time. Comments
can also be used to alert other ops that a ban should not be removed before
talking to you. Ngxbot sends you a query after you create a ban, telling you
how to comment on that ban. This makes it both very easy and very efficient to
add comments about bans, which makes managing future issues much easier.
- Don’t retaliate: If someone misbehaves, don’t retaliate. Take only the
appropriate actions to prevent further abuse (kick, ban, contact Freenode
staff). Retaliation is against the Code of Conduct and makes us
look bad as an operator team. As operators we expect users to retaliate when
we reprimand them. This is what a ban is for and if users attempt to evade a
ban we have further actions we can take. However, when operators retaliate it
can become extremely disruptive in a channel, especially if two operators
disagree. Retaliation from operators is unacceptable behavior.
When to Ban/Kick Someone
This is a summary of the current ad-hoc (generally accepted) guidelines used by
the operators.
- Flooding: mute
- Accidental flooding (pasting): mute and point to pastebin (remove mutes when
you think the paste is over)
- Swearing/off-topic: warn
- Repeated swearing/off-topic: quiet
- Someone who comes back after a kick and continues misbehaving: ban
- Trolling: ban
- Personal attacks against people: kick/ban
Examples of trolling:
- Repeatedly asking about other web servers or OSs
- Seeking for the limits of what’s allowed
- A lot of CAPS
- Being only negative about NGINX or other topics
Accidents Happen
After staying on IRC for a while, ops can get a bit trigger-happy. Don’t forget
that accidents do happen. Please don’t impose severe punishments on accidental
mishaps. In addition, users can make mistakes just as easily. It is expected
that operators can recognize when an accident happened and respond accordingly.