Re: [gentoo-council] User Relations authority

[Ferris McCormick <fmccor@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6165 bytes --]


On Tue, 2008-07-22 at 02:43 -0400, Mark Loeser wrote:
> Ferris McCormick <fmccor@gentoo.org> said:
> > 
> > On Wed, 2008-07-09 at 22:49 -0700, Donnie Berkholz wrote:
> > > From this month's agenda:
> > > 
> > >   User Relations authority
> > >   ------------------------
> > > 
> > >   Ferris asks: Does userrel have the authority to enforce the Code of
> > >   Conduct on users in the same way devrel does for developers?
> > > 
> > >   Preparation: Donnie will start a thread on the -council list. Post 
> > >   your opinion there. If everyone's posted in advance of the meeting, 
> > >   status check at meeting to see who's ready to vote.
> > > 
> > >   Goal: Reach a decision on-list no later than July 17.
> > > 
> > > Please respond with your thoughts.
> > 
> > I didn't even remember that I had asked this, but here are my thoughts.
> > 
> > 1.  Yes, Userrel has (or should have) that authority;
> 
> Cool, we agree that userrel has this authority.
> 
> > 2.  But for both devrel and userrel, the Code of Conduct loses almost
> > all its impact unless response is immediate --- CoC's intent, I think,
> > is to help keep the mailing lists and #gentoo-dev channel on track
> > pretty much in real time.  I know this was the original idea behind it,
> > and this was one reason we felt we needed people outside devrel to help
> > enforce it (devrel is not set up for immediate responses);
> 
> I think we should then make it so that userrel and devrel have the
> authority and/or power to respond immediately to problems in real time.
> Why isn't devrel set up to respond to problems "real time"?
> 

Historical reasons and lack of resources, I think.  As far as I know, we
(devrel) have always reacted mostly to complaints and sometimes
violations if we see them.  But we generally don't look.  You'd have to
check with christel, kloeri, and the 2006 Council generally, but I think
one reason for writing down the Code of Conduct and setting up the
proctors was to provide an alternative to the rather slow but
potentially serious devrel procedure for specific situations.  Most day
to day problems generally result just from loss of temper or personality
conflicts, and for those we wanted a way to act immediately but not with
starting up a lot of "machinery" or process.  Thus, the proctors were
supposed to take immediate action such as warnings, brief mediation, or
perhaps brief suspensions.

There was a fair amount of discussion about whether we should do this at
all, and whether it should become a devrel function.  Consensus was (1)
we needed it; (2) it should be done outside of devrel.

My original reaction was (1) No; (2) No.  I was mistaken on (1), and I'm
undecided on (2).  I *think* in (2) I'd probably give it to userrel.  As
someone pointed out, developers are users, too, and Code of Conduct is
supposed to apply uniformly across the board no matter who is in
violation.  Hence, userrel is probably better positioned to handle the
brief, sharp exchanges to calm them down before they erupt.

> > 3.  Thus, I think bugzilla bugs for Code of Conduct violations miss much
> > of the point.
> 
> If someone is abusing bugzilla to berate people, they should be
> punished.
> 

I agree, I think, but you misunderstand me.  What I meant to say was
that if someone opens a bug complaining about a code of conduct
violation, it's too late.  Process has broken down, because if we are
functioning correctly, most Code of Conduct violations should have been
snipped off before they can reach the open-a-bug-for-devrel/userrel
stage.

> > 5.  I am not sure where the current Code of Conduct document is, but
> > I'll volunteer to help update it to bring it into line with how we wish
> > to use it and to help clarify who has what authority under it, and that
> > sort of thing.  I have come to support it, and I'd like to help make it
> > more effectively used in the rather narrow context for which it was
> > designed before we consider extending its reach.
> 
> I'm not sure exactly what these statements mean.  Could you please
> elaborate on how you support it currently?  And what sort of changes you
> would like to avoid before you support the CoC further?
> 

By "support" I meant that I now agree with the principle behind it.  I
r4eally don't do much myself to enforce it, because I hardly ever see a
violation soon enough to react to it.  Everything else i said was out of
ignorance --- I don't know the current state of much of anything
regarding the Code of Conduct, but I am willing to help to make it a
real tool we can use.

> > 6.  For example, I think we could put some sort of limited moderation
> > onto the -dev mailing list, citing the current Code of Conduct as
> > authority, any time we wanted.  And I do not think the Code of Conduct
> > as currently envisioned has much reach into the past (one or two days,
> > probably; one or two weeks, perhaps; one or two months, no; one or two
> > years, certainly not).
> 
> So you wish to limit the reach of its timeframe?  Could you please
> elaborate on what you mean here?  I'm not sure what you are trying to
> express.
> 
> Thanks,

Sure.  The Code of Conduct/Proctors structure was set up to handle
problems as they occur.  Others involved in the initial concept might
have viewed it differently, but I always have viewed the whole idea to
be simply to keep Gentoo as civil as practical on a day to day basis.
True, repeated violations could result in increasingly severe sanctions.
But the idea as I have always viewed it was to address today's fires
today.  Not yesterday's fires today, not today's fires tomorrow.  This
requires a quick reaction team, and that's what the proctors were for.

Hope this helps,
If I'm still confusing people, please just ping me.  I'll try to clear
up anything on IRC if you wish (but no need for any of this to be
private; #gentoo-qa or #gentoo-userrel would either be fine).

Regards,
Ferris

-- 
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]