#ubuntu-ops policy discussion

[Juha Siltala]

On 02/01/2010 04:16 PM, Juha Siltala wrote:
> According to the current policy, we allow no idling on the channel by
> non-operators. Users should only visit the channel when they have
> outstanding issues that require operator assistance. The purpose of
> this policy is to ensure that ops and users can work out any issues
> without spectators or intrusions by those not directly involved. It
> also allows ops to quickly recognize anyone in need of assistance by
> noticing that they are not voiced. Transparency is achieved by having
> channel logs[2] publicly available.
After reading a day's worth of comments, I think it's time I chip in my
opinion as well.

In short, I would like to see what exactly is wrong with the current
policy described above.

Pricey says we've been told that it does not work, and that he agrees.
This is not a very strong argument in itself and should be elaborated a
little more clearly. How is #ubuntu-ops broken? We do get issues solved.
No doubt we can do our jobs better as ops and improve our negotiating or
helping skills, but how is changing channel policy going to improve our
personal skill?

There is a call for handling more issues in /queries instead of the
channel. We can talk certainly talk about that, but I don't see how it's
related to the no-idle policy. For the record, most of us already do use
/queries extensively, and move the discussion to the -ops as required,
usually after failing in query. We can agree to increase (or decrease)
query use, but there is no data on the amount of queries vs. channel
discussions so I can't really say how we're going to track progress.

As for Pricey's request that we should stop using -ops for "group-led
dispute resolution", we *don't*. We are not supposed to jump into
discussions between an operator and an user without a very good reason.
Any such incident is a bug, it should not happen. No policy change is
required for that. To make this clear, one operator is supposed to
handle each discussion *already*.

Lurking has been defended on a possibility to learn from following
channel discussions. I fail to see what learning challenge could be
aided by that, or why live lurking is superior to studying the logs
which already are available.

Some commenters have been worried about privacy and users being
humiliated on -ops. Aside from the practice of handling issues in
queries (which we already do), two points apply, *neither* of which are
related to the no-idle policy that we are now supposed to discuss:

   1. There is no privacy as it is, since the -ops log is public.
      Furthermore, privacy and IRC are incompatible anyway.
   2. Humiliation should never happen. We exist to serve ubuntu users.
      If a user is humiliated by an operator or operators while
      discussing an issue, I would like to know about it, *every time*,
      as the operator in question is clearly out of line and in
      violation of our operator guidelines as well as the community code
      of conduct.

There has been a vague call for more transparency. My question is,
again, why is the current level of transparency enough? This smacks of
something picked up from popular press. Everything that happens on the
channel is public! How do you improve on that?

A separate, open discussion channel has been suggested. What exactly
would we discuss there? Users can already join -ops and ask questions.
On the other hand, a separate, *private* discussion channel has also
been discussed. We can create such channels any time, and if there's a
need, we will open and close them as needed. Do we need the IRCC to tell
us that yes, we can do that?

So, for the record, I am advocating doing *nothing* about the current
policy until someone explains its brokenness in language clear enough
for me to understand. The burden of proof is on those requesting
changes, not on those maintaining a system that already works.

-- 
Juha Siltala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-irc/attachments/20100202/84c710b7/attachment.html>