Request for Feedback: Document on dealing with Ubuntu IRC Problem Users

Michael Lustfield mtecknology at
Fri Jan 14 05:38:30 UTC 2011

On Thu, 13 Jan 2011 13:26:11 -0600
Nathan Handler <nhandler at> wrote:

> Hello everyone,
> At the last IRC Council meeting, we decided to send a copy of a
> document [1] that explains how to deal with Ubuntu IRC problem users
> to the mailing list for feedback. I am including a copy of the
> document inline to make it easier for people to comment on particular
> sections of it.
> Thanks,
> Nathan Handler
> On Behalf of the Ubuntu IRC Council
> [1]
> _____
> There are many technical as well as social methods for dealing with
> users causing problems in an IRC channel. In most cases, if the
> problem is not very serious or urgent (i.e. someone includes a few
> swear words in their messages), the first step that should be taken is
> a simple public warning in the channel. Something like, "foo: This is
> a family-friendly channel, please do not swear in here". Many times,
> this will be sufficient to resolve the problem, and then everyone can
> happily return to going about their business. If this does not work
> and the user continues to carry out their problematic behavior in the
> channel, a quiet can be set. Once the quiet is in place, if it was set
> via ChanServ, please acknowledge that you set the quiet in
> #ubuntu-ops. You should also immediately follow it up with a private
> message to the user. In this PM, try and explain in a bit more detail
> why their behavior is a problem, link them to the specific
> rule/guidelines that they are violating, and try to work with them to
> reach an understanding and resolve the problem. If the problem is
> resolved, the quiet can be removed. If not, leave it in place for a
> little while to give the user some time to think about their actions a
> bit more. Try and talk to them again in PM in a day or so. An unedited
> raw transcript of the PM conversation should be added as a comment for
> the quiet on the bantracker so that other operators are aware of the
> situation and how it is being handled.
>     A quiet will keep the user from talking in the channel, which
> should prevent them from violating the rules. However, there are a few
> instances where a quiet is just not sufficient. For example, some
> users, upon being quieted, will decide to start joining/parting the
> channel very quickly in order to flood it with join/part messages. A
> quiet will do nothing to stop this. Instead, a ban should be used. Be
> sure to follow the ban up with a PM just like above. Another instance
> where a ban might be necessary is for a user with an inappropriate
> nickname who refuses to change it.
>     Operators are not expected to be perfect and know how to deal with
> every problem on their own. If you are having issues working with a
> user in PM, you can refer them to #ubuntu-ops for other operators to
> help. This should not be the first step when dealing with the user;
> instead, you should try and resolve the problem yourself first.
>     Some users insist on trying to evade bans that are set on them.
> This might be done accidentally due to a poorly constructed ban
> string. Look over your ban and possibly ask another operator for help
> in correcting it. If the user is clearly intentionally evading, talk
> to them and try and explain why evading is discouraged. If you can't
> get through to them, maybe try having other operators talk to them in
> #ubuntu-ops. Finally, if the issue persists, contact a member of the
> IRC Council. They will review the issue and escalate it to freenode
> staff if necessary.
>     Remember, as an operator, you have agreed to spend the extra time
> and effort to deal with these users. You are also expected to abide by
> the Ubuntu Leadership Code of Conduct
> (, the normal Code
> of Conduct (, the Ubuntu IRC
> Guidelines (, and the Operator
> Guidelines ( at
> all times. If you quiet or ban a user, it is your job to follow up
> with a PM. If you do not have the time to deal with a user, ask
> another operator in #ubuntu-ops to do so, but it is your
> responsibility to find another op to help you out.

That looks like a great little document. I think it's a great start but should
definitely be expanded upon. After reading through it, it seems to be somewhat
of a template for what should be "common sense" which makes me like it even

I also wanted to mention this:
"In this PM, try and explain in a"
-> "In this PM try to explain in a"

More information about the Ubuntu-irc mailing list