IRC Issues [From Stepping Down]

[Michael Lustfield]

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



On Fri, 2 Oct 2009 23:51:06 +0300
Jussi Schultink <jussi01 at gmail.com> wrote:

> On Fri, Oct 2, 2009 at 9:01 PM, Michael Lustfield <mtecknology at ubuntu.com>wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Just a short note before I head to bed.
> >
> > 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.
> >
> In my understanding we already have such a thing - its called the ban
> tracker. Unfortunately its not scalable enough right now to ope to the
> public, but you can add to the blueprint on LP (Bantracker two).
I wasn't aware this was ever going to be opened. I was under the
impression it was intended for the ops team only. If this included
resolutions to any appeals, I'd consider this about the same.
> 
> > >
> > >
> > > > 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
> >
> Thats All Ill say for the min as I need to go to bed.
> 
> Jussi Schultink. (jussi01)
> 
> >
> > Network and Systems Administrator
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAkrGP+oACgkQ3y7Nst6YLGUMAgCfXTcUbqL2RaEYETkuQUPtyj/u
> > scMAoJdudeLVo5sEfx2OQZP/R3Eb3T69
> > =LG3X
> > -----END PGP SIGNATURE-----
> > --
> > Ubuntu-irc mailing list
> > Ubuntu-irc at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-irc
> >


- -- 
Michael Lustfield
Kalliki Software

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

iEYEARECAAYFAkrGb+wACgkQ3y7Nst6YLGUDSwCeMxF2N4ZhFVFFLmjpBbnS+Air
oHIAnioAAdpNlmkBnWlXJsk4yR1fQX/J
=2Thg
-----END PGP SIGNATURE-----