IRC/wikipedia/Channel operator guidelines

This set of guidelines was created by #wikipedia ^connect and #wikipedia-en ^connect channel operators ("ops") (list available here) following a series of private ops' meetings. The document explains the guidelines that should be followed by all operators when certain issues arise in the channels. While these guidelines were created specifically for #wikipedia ^connect and #wikipedia-en ^connect operators, other channels may wish to adopt them for their own use.

As a channel op, you are expected to:

• catalyse , even in sometimes difficult situations
• within reason, idle in #wikimedia-ops ^connect while online in #wikipedia and/or #wikipedia-en
• gain second opinions when necessary in #wikimedia-ops ^connect

In nearly all cases (exceptions are noted below), it's best to talk to the user in a private message before taking operator action

Use your ops sparingly. If a channel is set +t, like #wikipedia is, change the topic by typing: "/msg chanserv topic #wikipedia <topic goes here>". When you op-up, only keep your ops for as long as required - then de-op once you are done. Do not attempt to op users that are not ops in the channel.

This is not to say that if a dozen bots are coming into the channel, opping/deopping is sensible - the justification behind this idea is to reduce "noise".

You'll probably use this the most when you are using your operator access. A quiet is usually enough to solve any problems, as it allows you to discuss (in PM) the situation with a user, without them getting extremely angry that you banned them from the channel. Quiets should be used with:

• Flooders
• Spammers
• Trolls
• Nick change spammers - +q stops them.

The justification for this is that the forcible removal of a user from a channel is, in nearly all cases, a disproportionate response, and really can just amount to releasing tension (on the ops' part). This is perfectly understandable if the user has been a pain, but it's fairly critical to remember that we should at least try to talk to the user and resolve the issues. If we've removed them from the channel, their prejudice against us is consequently higher than if we take the "kinder" option of quieting. Be aware that other users in the channel may expect/demand a "kickban" – remember that you're the one with the tools, and don't allow them to sway you!

Bans (+b) should be used with:

• Join/part flooders

Justification: this is the only time a ban is needed (NB: this also applies to users with apparently broken connections – see below).

• A user shouldn't be banned solely due to actions/bans from another channel.
• If the user has been banned due to disruptive action in #wikipedia ^connect , particular care should be taken to observe the user in #wikipedia-en ^connect , and the same also applies in reverse.
• Consulting other ops in #wikimedia-ops ^connect is advised before cross-channel banning (unless the reasons are obvious as stated above).

Justification: We are, simply put, better ops than most other channels and we may be able to deal with someone a bit better. This doesn't mean we close our eyes and let them have a free rein though, and it's very wise to take their behaviour elsewhere into account if they start to play up (though it is still worth trying to catalyse).

• If a user evades a ban, discuss with them in PM, asking them to leave the channel as they are ban evading.
• Re-ban the user if the above fails.
• Do not escalate a quiet to a ban due to evasion without discussion in #wikimedia-ops .
• Discuss with other ops in #wikimedia-ops ^connect if you are stuck with anything.

Justification: there's no point causing extra drama if the matter can be resolved calmly. Sometimes users will be evading bans by mistake!

See the freenode catalyst guidelines for more info.

• Basically, catalysing means handling situations in channels without using your Ops. This can take the form of being the calm voice in an argument, or PMing the user that is causing a disruption to try and work things out.

Flooding can be disruptive to everyone in the channel, so it must be dealt with as quickly as possible.

• If a user has paste-flooded, /remove #channel nick them, and then tell them to rejoin once they are done, however if they autorejoin and continue +q them and PM them telling them to tell you when the buffer has run out. You can then unban them from the channel as it was most likely an accident.
• If a user maliciously floods, then +q them. You can discuss with the user afterwords in a private message about their actions, and discuss with other ops in #wikimedia-ops ^connect if they should be unbanned.
  • If multiple users maliciously flood, chances are they are doing this in multiple channels – a note to staff in #freenode ^connect would be nice in addition to quieting.

When dealing with discussions that are getting the channel temperature high and/or if "off-topic" topics are brought up in the channel:

• Keep an eye on the channel, to make sure everything is OK.
• PM the people who are involved in the discussion, asking them to "cool down" or "get back on topic" nicely.
• If this fails, get help from your fellow ops in #wikimedia-ops ^connect . It is much easier to steer the conversation in channel when more than one person is trying to do it.
• If steering the discussion in another direction and catalyzing both fail, it may be appropriate to +q the users who are causing the problems, and then explain in private message and further attempt to catalyze.

• Ops should remind users that stalk words are to be used once, on the same line as the request such as !op UserABC is spamming.
• If a user maliciously abuses a stalk word: such as "!admin YOU ALL SUCK!", then ops should consider immediately +qing them.
• If a user abuses a stalk word, they should be warned by an op before the op can take action. If a user abuses or misuses a stalk word after warning(s), an op can consider +qing them.
• After you have +qed the user, then you should PM them to discuss the action; alternatively, invite the user to discuss it in #wikimedia-ops ^connect for a wider viewpoint.

Talking bots are not allowed in the channels.

• If a talking bot joins the channel, +q it.
• If a bot evades a +q, then +b it.
• Where possible, discuss with the owner of the bot in PM asking them to stop, if they don't listen -> then you can +b them from the channel (along with any other bots that come along).

• If a single user complains that they are being annoyed by another user via a private mesasge, tell them to /ignore the user.
• If multiple users complain that they are being annoyed by another user via a private message, the users should /ignore the problem user, and the op should attempt to catalyse . Failing this and continuing disruption to multiple channel users could be reason for a ban.
• If an op is being annoyed by a user, the same concept applies, however the op should attempt to catalyze if possible, or if not possible discuss in #wikimedia-ops ^connect .

• Single: catalyse
• Repeated: Ban (+b) and report to freenode staff in #freenode ^connect , ops should be pinged in #wikimedia-ops ^connect by AntiSpamMeta automatically.

• If a user says in plain text in the channel a DCC "trigger" string, then ops should +q them, and then report to freenode staff in #freenode ^connect .

• Join/part flooding as a result of a malfunctioning connection: If you can't talk to the person, create a temporary redirect ban to an overflow channel such as ##fix_your_connection ^connect (like this: n!u@h$##fix_your_connection) or #wikimedia-overflow ^connect . The ban length should be set for a short duration. It's worth sending a PM while they're online (even if they're cycling a lot) so that they can see why/by whom they've been banned when they get back.

You've been given access because you have at least some of this. Do use it! :)

For everyday issues

• Ops should use their chat client's feature to be highlighted when "!ops" is said in channel.
• If an op is unsure about something, they should discuss with other ops in #wikimedia-ops ^connect , or for private matters, #wikimedia-ops-internal ^connect .
• If you need the attention of other ops, don't be afraid to use the "!ops" stalk word, but don't abuse it!

For larger issues

• If larger issues come up, such as DCC exploits, you should report them to a freenode staffer in #freenode ^connect .
• A few freenode staffers idle in #wikimedia-ops ^connect , so you can also report to them there.

• Pages that need updating
• IRC