IRC Issues [From Stepping Down]

[Michael Lustfield]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Fri, 2 Oct 2009 19:20:03 +0200
Lasse Havelund <lasse at havelund.org> wrote:

> > I also think any resolutions to these issues should be documented. This
> > could allow us to have a precedence for further issues. We already have
> > a list for how operators should behave. This could be just an addition.
> > I could set up a nice page for this that would have categories for
> > resolved, not resolved, and being resolved. Just like how the BBB works
> > except in a public manner. Of course some of these issues will need to
> > move to IRCC for a multitude of reasons. It would still be nice if a
> > generic result could move to this.
> I think we need to be careful about creating a list with instruction on
> exactly how to deal with a problem. In my experience, most of them are
> better dealt with on a case-to-case basis. Guidelines I can see the idea of,
> but actually creating an 'answer booklet' is not the way to go. Let the
> person dealing with the issue handle it - after all, there is a reason we
> were appointed ops in the first place.
The point was that some ops handle things entirely different from
another. Some ops will take offense to a person saying "holy crap" and
issue a kick where others don't flinch at swearing. I keep referring to
language since it's an easy one to associate with.  I never said it
needs to be a list of "instruction on exactly how to deal with a
problem" but rather a set pf precedents. "precedent - an example that is
used to justify similar occurrences at a later time" For example, user 
kicked for "holy cow." Issue appealed and it's decided this is fully
acceptable. Next step is to clarify for current and future ops that
this has been deemed acceptable. If this is questioned, a detailed
explanation why this is acceptable would be readily available. There's
no reason it should cover every situation. Indeed some situations do
call for a judgment call from an experienced op. In these situations
the resolution shouldn't be recorded in a generic sense. However, I see
a set like this helping in some of the common mistakes. This list would
be readily available for anyone that wold like to appeal a decision
where the decision would have been in the 'maybe/maybe not' category.
In this situation, the op would have that precedent to back up the
decision they made. This such as an excessive flooding ban, those are
generally either cut and dry or a judgment call. No reason for that to
be on this list. Arguing [not trolling] between two different users
should find it's way to that list. 
> 
> 
> > One interesting thing I learned from my segway into Gentoo (which was
> > really fun) is how they handle bad language. They define bad language
> > as ${EXPLETIVE}. This includes "hell" as well as other words that are
> > generally considered acceptable unless overused. They follow a pretty
> > specific policy. If it falls into this category, there's warn, ban, ban
> > long time. They don't draw a grey line. It either is, or it isn't. This
> > is a policy that I feel we should adopt. Perhaps not at the 'long time'
> > length they hand out however.
> 
> Absolutely not a good idea. I'm going to have to say I agree entirely with
> Lorenzo on this one.
What I said wasn't in relation to the specific actions used. It was
pertaining to the language used. It's already pretty clearly defined
what to do with a !language violation. What is very much not clearly
defined is what constitutes a violation. This is what I was trying to
get at on this subject. I do agree that I didn't make my point clear
here and I'm sorry it came across as such.
> 
> /Lasse Havelund [MenZa]

Hopefully this clears up everything I was leading into.
- -- 
Michael Lustfield
Kalliki Software

Network and Systems Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrGP+oACgkQ3y7Nst6YLGUMAgCfXTcUbqL2RaEYETkuQUPtyj/u
scMAoJdudeLVo5sEfx2OQZP/R3Eb3T69
=LG3X
-----END PGP SIGNATURE-----