RE: [srvx-devel] Support Additions

[Zoot <zo...@pl...>]

Looking at this from the technical standpoint, implementing the scheme
you suggested should be easy, but I wonder if this is really the
solution to the general problem of keeping helpers in line. Currently,
helpers with security override have virtually the same access to
ChanServ as full opers, yet most handle a relatively small set of
problems: users want general IRC or GamesNET help, they want their
handles opened so they can authenticate, or they want to register a
channel. Perhaps the level one helpers could have access to only the
commands necessary to handle those problems, while level two helpers
have full security override. I don't want to tell the support committee
what to do, but I think it's a reasonable suggestion.

A hierarchy of helpers would be great. I'd like to point out that as
helpers climb the ladder, they shouldn't simply be given more
permissions and yet be responsible for the same old, routine duties.
Helpers might start out in #support, but they should be given new and
different jobs as they advance; for example, they could be appointed to
police channels that request a helper's presence. (Say, busy channels
that suffer lots of lamers, or release parties/events, etc.) A hunger
for power can be a healthy motivator, but I'm not sure that we want
people whose only motivation is to get that O:line. A better motivation
is that they enjoy what they're doing. (I know I like working on srvx,
for example -- if all I was getting out of it was the hassle of an
O:line and a front row seat to network politics, I'd be gone in a
second.) I'm sure there are lots of interesting aspects of network
operation that the helpers would really, truly be happy to handle, given
the appropriate helpers get the job. Heck, I'm sure every committee,
including routing, development, web, services, PR, has some work or
project that hasn't been getting attention for lack of time or people:
let the helpers apply for the job! They can get the sense they really
are contributing.

Right now, it seems this needs immediate fixing. If we'll be kludging up
a quick fix, we would need to know what each level does and doesn't have
access to. For 2.0, I'd really like a more general solution that doesn't
require new code to implement new and different access control schemes;
new "levels" of helpers could be created and existing levels modified,
and authorization would be completely unified across all services. I'll
be writing up a proposal later today. I'm sorry this turned into another
essay, oops.

# Zoot