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

[Jussi Kekkonen]

On 14 January 2011 07:14, John Chiazzese <oneidle at gmail.com> wrote:
> I understand the need for such a document.It is a decent "guide" to how
> things should be handled. New ops and even some older ops could benefit
> from following this guide (myself included).
>
> I would like to see it clearly stated that this document is a suggested
> method of handling certain situations and not a firm set of steps that
> an op must follow. I fear that a document of this type would/could be
> used against an operator by users (trolls) who want to argue the
> reasoning for a quiet/removal/ban and state that the policy was not
> followed so the ban should be removed.
>
> IdleOne
>
> On Thu, 2011-01-13 at 13:26 -0600, Nathan Handler 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] https://docs.google.com/Doc?docid=0ASFFoXLMT-guZGhoZmZxNG1fNTYyaHB3NzNxZGM&hl=en&authkey=CNCQ__wP
>>
>>
>> _____
>>
>> 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
>> (http://www.ubuntu.com/community/leadership-conduct), the normal Code
>> of Conduct (http://www.ubuntu.com/community/conduct), the Ubuntu IRC
>> Guidelines (https://wiki.ubuntu.com/IrcGuidelines), and the Operator
>> Guidelines (https://wiki.ubuntu.com/IRC/IrcTeam/OperatorGuidelines) 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.
>>
>
>
>
> --
> Ubuntu-irc mailing list
> Ubuntu-irc at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc
>

What IdleOne said, good guide and I like it (although I would suggest
sometimes a smaller issues being said in PM first if it's not outright
against our rules, thus less chance escalating by public pointing).

My only concern now is that it's not stated if this is meant to be a
firm rule or just a suggestion/recommendation as a way to do.And yes,
I would rather not see it as a firm rule, atleast not as a whole.
Perhaps splitting the bottom part which states the responsibilities as
a rule and the rest as suggestion/guide/younameit or something along
those lines?

Will comment more later, huggles all.

-- 
Jussi Kekkonen, Tm_T
  Ubuntu/KDE developer  tmt at ubuntu.com