[gentoo-project] CoC round 2 (or is it 10? ;)

[gentoo-project] CoC round 2 (or is it 10? ;)

[Steve Long]

Chrissy Fullam wrote:
>> Donnie Berkholz wrote:
>> Here is the summary from today's council meeting. The
>> complete log will show up at
> <snip>
> - The CoC is in effect, but it needs a new enforcement section since the
> proctors were disbanded. The council is sending discussion of this to
> the gentoo-project list, to come up with proposals for three points:
> - who enforces it
> - musikc said devrel could
> - tsunam said userrel could
> <snip>
> 
> I wanted to clarify, please understand the intent behind my part of the
> conversation was that devrel and userrel should continue to share the
> responsibility as appropriate, and continue to work together, including
> the questionable/overlapping areas. The above may have been misinterpreted
> by some to indicate 'pick which one', when my intent was a joined front on
> enforcing the CoC.
>
That seems reasonable, since the two groups who need equal treatment in an
even-handed, impartial manner, are the users and the devs. I'd be happier
if user-reps were considered for the pool as well, since devs all seem to
know each other fairly well and are quite a close-knit virtual community.
Closing ranks happens: deal with it or not. *shrug* YMMV.

>> Donnie Berkholz wrote: 
> >         - how to enforce it
> >                 - whether it's active or passive enforcement
Er well I'd say passive enforcements what you've had so far (at least as far
as the dev m-l, which is where many issues seem to surface, goes) and it
hasn't worked out very well, which was why there was the long "discussion"
on dev[1] followed by the decision to establish the proctors[2].

> >                 - which actions are appropriate
> >
IMO muting a thread/locking a forum post/setting irc +m for 24
hours/forever/however long the ops think it needs, with email/privmsg/pm
discussion with whichever people are most vociferously flaming each other
(as decided by the mods.)

> > - If the -project list does not come up with a draft, dberkholz will 
> > write one based on -project discussion to vote upon at the November 
> > council meeting.

Of course, you're going to need people who have experience of forum
moderation, since that's the closest to email. IRC ops can overreact in
this context, since they have to close a flamewar/cursing-match/abusive
situation down in real-time, so their instinct is naturally to set +b for
the medium.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/46339/focus=46611
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/46780


-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] CoC round 2 (or is it 10? ;)

[Roy Bamford]

On 2007.10.14 13:39, Steve Long wrote:
> Chrissy Fullam wrote:
> >> Donnie Berkholz wrote:
> >> Here is the summary from today's council meeting. The
> >> complete log will show up at
> > <snip>
> > - The CoC is in effect, but it needs a new enforcement section 
> since
> the
> > proctors were disbanded. The council is sending discussion of this
> to
> > the gentoo-project list, to come up with proposals for three 
> points:
> > - who enforces it
> > - musikc said devrel could
> > - tsunam said userrel could
> > <snip>
> > 
> > I wanted to clarify, please understand the intent behind my part of
> the
> > conversation was that devrel and userrel should continue to share
> the
> > responsibility as appropriate, and continue to work together,
> including
> > the questionable/overlapping areas. The above may have been
> misinterpreted
> > by some to indicate 'pick which one', when my intent was a joined
> front on
> > enforcing the CoC.
> >
> That seems reasonable, since the two groups who need equal treatment
> in an
> even-handed, impartial manner, are the users and the devs. I'd be
> happier
> if user-reps were considered for the pool as well, since devs all 
> seem
> to
> know each other fairly well and are quite a close-knit virtual
> community.
> Closing ranks happens: deal with it or not. *shrug* YMMV.
> 
> >> Donnie Berkholz wrote: 
> > >         - how to enforce it
> > >                 - whether it's active or passive enforcement
> Er well I'd say passive enforcements what you've had so far (at least
> as far
> as the dev m-l, which is where many issues seem to surface, goes) and
> it
> hasn't worked out very well, which was why there was the long
> "discussion"
> on dev[1] followed by the decision to establish the proctors[2].
> 
> > >                 - which actions are appropriate
> > >
> IMO muting a thread/locking a forum post/setting irc +m for 24
> hours/forever/however long the ops think it needs, with
> email/privmsg/pm
> discussion with whichever people are most vociferously flaming each
> other
> (as decided by the mods.)
> 
> > > - If the -project list does not come up with a draft, dberkholz
> will 
> > > write one based on -project discussion to vote upon at the
> November 
> > > council meeting.
> 
> Of course, you're going to need people who have experience of forum
> moderation, since that's the closest to email. IRC ops can overreact
> in
> this context, since they have to close a
> flamewar/cursing-match/abusive
> situation down in real-time, so their instinct is naturally to set +b
> for
> the medium.
> 
> [1] http://thread.gmane.org/gmane.linux.gentoo.devel/46339/
> focus=46611
> [2] http://thread.gmane.org/gmane.linux.gentoo.devel/46780
> 
> 
> -- 
> gentoo-project@gentoo.org mailing list
> 

Steve,

Some interesting points ... control of any written channel can only be 
passive, in the sense that controllers are always responding after the 
event. The possible exception is a moderated mailing list.

How are passive and active defined in this context then?
Passive would have to be the controllers wait for a complaint before 
acting and active would be the controllers work in as close to real 
time as the medium allows, on things they notice for themselves as 
happens in IRC and forums. They are always reactive regardless.

Most of the proctors actions were carried out in private, this seemed 
to work best since most people hate to be publicly asked to exercise 
restraint. We don't need a new project to continue this sort of 
activity, nor do we need to add to the scope of any existing project. 
Anyone can do it anytime. Curbing the worst excesses of friends is one 
of the things we can all do for one another. Continued poor behavior 
should be referred to the appropriate body in the normal way.

The -dev mailing list seems to have calmed down since the proctors most 
public action, when a number of users had their posting rights 
suspended briefly. I'm unsure if the creation of -project played a big 
part in this or not. Judging by the number of posts to -project, I 
think its unlikely. I'm more inclined to believe that the bloodletting 
on that particular thread was something that everyone was aware of 
and nobody wanted to risk repeating. Thus the proctors served their 
purpose.

Regards,

Roy Bamford
(NeddySeagoon)
Is/was a member of
gentoo-forums
gentoo-ops
gentoo-treecleaners
gentoo-proctors


--
gentoo-project@gentoo.org mailing list

[gentoo-project] Re: CoC round 2 (or is it 10? ;)

[Steve Long]

Roy Bamford wrote:
> Some interesting points ... control of any written channel can only be
> passive, in the sense that controllers are always responding after the
> event. The possible exception is a moderated mailing list.
> 
> How are passive and active defined in this context then?
> Passive would have to be the controllers wait for a complaint before
> acting and active would be the controllers work in as close to real
> time as the medium allows, on things they notice for themselves as
> happens in IRC and forums. They are always reactive regardless.
>
I concur that it is only ever reactive. I take active v passive, in the
context of the mailing list, to mean the use of public mutes, similar to a
forum thread being locked because it has descended into flames vs allowing
the flames to continue and taking action via devrel, which rightly takes a
long time, since it is about a dev's conduct over a period of time, not
about one heated discussion.

(If you cover how devs will be moderated, the same can apply to users with
no issue. The inverse does not apply, unfortunately, due to the culture of
the group under discussion.)

> Most of the proctors actions were carried out in private, this seemed
> to work best since most people hate to be publicly asked to exercise
> restraint. We don't need a new project to continue this sort of
> activity, nor do we need to add to the scope of any existing project.
> Anyone can do it anytime. Curbing the worst excesses of friends is one
> of the things we can all do for one another.
Agreed, wholeheartedly.

> Continued poor behavior should be referred to the appropriate body in the
> normal way. 
>
Yes that's the situation at present, and was the situation before the whole
CoC discussion. It didn't work before, and with respect, I don't think
it'll work in future, should the need arise.
 
> The -dev mailing list seems to have calmed down since the proctors most
> public action, when a number of users had their posting rights
> suspended briefly. I'm unsure if the creation of -project played a big
> part in this or not. Judging by the number of posts to -project, I
> think its unlikely. I'm more inclined to believe that the bloodletting
> on that particular thread was something that everyone was aware of
> and nobody wanted to risk repeating. Thus the proctors served their
> purpose. 
> 
By falling on their swords? I think that was unfortunate, to use a
euphemism. The problem is, there's nothing to stop the situation recurring
in the future, at a point where the people involved have no memory of that
bloodbath.

I think the existence of project means people can be referred here (not just
told not to discuss something.) It's unfortunate that there is dev snobbery
wrt this list (I've seen "take it to project" used almost as an insult and
no-one has ever done so) but hopefully that'll change, when more
interesting discussions do take place on here. (Responding to non-technical
aspects by posting the reply to project instead of dev would help.)

I think the commit-reviews have also helped, since there is much more
technical discussion going on, and it's keeping people's minds on the
day-to-day business of maintaining the tree.

On the larger question of how to enforce, I think having a group that is
prepared to act publically, iff required, does two things: it takes the
onus off of individuals to challenge bad behaviour (which can be hard) and
it sends a signal that certain behaviour will not be tolerated-- that there
are boundaries, and they will be enforced if necessary. Both are vital to
my mind.

It helps if the use of such a power is a) carried out as impartially as
possible (ie by a group suitably constituted for that purpose, not on one
dev's whim, with transparent involvement of all parties in the discussion--
*before* an individual is banned, should it come to it) and b) supported by
the Council when the team, as a team, has decided to act. The latter is of
course what killed off proctors.

Another helpful thing would be if it were not seen as such a major
imposition on people's freedoms for *one* thread to be locked. Users don't
get all melodramatic about it: why should devs?

Passionate discussion is to be expected and indeed welcomed, since that's
the nature of voluntary communities: people are involved because they want
to be. As such, it shouldn't be a big deal if discussions get heated, so
long as they stay civil. The behind-the-scenes activity you mention is
important, but there has to be the will to act publically when needed, or
unchecked flamewars *will* happen again imo, at some point. That's the
nature of the beast.


-- 
gentoo-project@gentoo.org mailing list

Re: [gentoo-project] CoC round 2 (or is it 10? ;)

[Ferris McCormick]

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

Please note that in what follows I speak only for myself, but from the
perspective of a Devrel member concerned with Conflicts Resolution.  I
explicitly do not speak for Devrel, nor have I reviewed what I say with
anyone in Devrel.

On Mon, 2007-10-15 at 17:22 +0100, Roy Bamford wrote:
> On 2007.10.14 13:39, Steve Long wrote:

=== Large snip ===

> Steve,
> 
> Some interesting points ... control of any written channel can only be 
> passive, in the sense that controllers are always responding after the 
> event. The possible exception is a moderated mailing list.
> 
> How are passive and active defined in this context then?
> Passive would have to be the controllers wait for a complaint before 
> acting and active would be the controllers work in as close to real 
> time as the medium allows, on things they notice for themselves as 
> happens in IRC and forums. They are always reactive regardless.

It was my understanding that this was one of the distinguishing points
between the Code of Conduct/Proctors and the existing Devrel structure.
It seems rather clear to me, at any rate, that the Code of Conduct is
normative:  It lays out in general terms boundaries for acceptable *real
time* behavior in the various Gentoo communications media.  The
Proctors, I believe, were established as a policing body for this
(recall my "traffic cop" analogy; I think it holds up).  I would
consider this to be "active" control.

Contrast this with how Devrel policy reads.  Devrel policy is pretty
clear; to quote from Policy, "Developer relations should only be
involved in a conflict when other attempts to solve the issue have
failed."  Thus, except in extreme situations, by current policy Devrel
is explicitly NOT a "traffic cop."  Devrel takes official notice when
someone "rings our bell" (to quote from IRC --- it's an in-joke).  I
would consider this to be "passive" control.

Now, Council might not like it that way, but in my opinion (I speak for
myself here), we must live with the policy as it reads, not as how we
might like it to read.  And, again speaking for myself again, I think
composition of Devrel reflects that:  I have always been involved with
Conflicts Resolution and prefer to work as a mediator; I have little
interest in "policing" mailing lists or IRC.

> Most of the proctors actions were carried out in private, this seemed 
> to work best since most people hate to be publicly asked to exercise 
> restraint. We don't need a new project to continue this sort of 
> activity, nor do we need to add to the scope of any existing project. 
> Anyone can do it anytime. Curbing the worst excesses of friends is one 
> of the things we can all do for one another. Continued poor behavior 
> should be referred to the appropriate body in the normal way.
> 
Absolutely.  I'll metion that Devrel mediations are of necessity private
as well.  A mediator holds a position of trust, and implicit in that is
that the mediator will not post private conversations will not on
bulletin boards.  As for the rest of the statement, all I can do is
concur.

> The -dev mailing list seems to have calmed down since the proctors most 
> public action, when a number of users had their posting rights 
> suspended briefly. I'm unsure if the creation of -project played a big 
> part in this or not. Judging by the number of posts to -project, I 
> think its unlikely. I'm more inclined to believe that the bloodletting 
> on that particular thread was something that everyone was aware of 
> and nobody wanted to risk repeating. Thus the proctors served their 
> purpose.

I think it's calmed down, too.  I'll note that at the moment, from what
I've seen, Devrel (Conflicts) is getting very little "action" as well.

I'll use this as a vehicle to throw some oil onto the fire.  There seems
to be a consensus for folding the old Proctor function into
Devrel/Userrel.  Of course, this has some implications:  Devrel, for
example, is structured to support it's policy as it is now.  We can fold
the Proctor function into Devrel/Userrel, of course, but this has both
staffing implications and inter-group interaction implications.
Personally, I think we'd end up establishing the Proctors by another
name.  What is the argument against just reestablishing the Proctors and
be done with it?  Experience shows that however we do it, there will be
start-up problems as both the Code of Conduct comes better into focus
and people play with what does work and what does not.  And
responsibility for the function should not lie with Council:  we are
talking about a Gentoo Project (perhaps in Devrel/Userrel) meant to last
longer than any specific Council.  Like it or not, individual Councils
are short term.

As Roy points out above, we actually do not need the Proctors by any
name if the community in general polices itself effectively.  Indeed,
one of my goals as a Devrel mediator, or anyone's goals working in a
policing function, must be to establish an environment where the
function itself becomes unnecessary.  I am not sure this is achievable,
but thus the ongoing discussion of Code of Conduct.

> Regards,
> 
> Roy Bamford
> (NeddySeagoon)
> Is/was a member of
> gentoo-forums
> gentoo-ops
> gentoo-treecleaners
> gentoo-proctors
> 
As always, comments, questions, suggestions welcome.  Feel free to keep
pure flames to yourself. :)

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


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

RE: [gentoo-project] CoC round 2 (or is it 10? ;)

[Chrissy Fullam]

I hate long emails so I apologize in advance. Most of this is just showing
what I base my own comments on in the hope that it makes more sense that
way. :)


> > How are passive and active defined in this context then?
> > Passive would have to be the controllers wait for a complaint 
> > active would be the controllers work in as close to real time.
> 
> It was my understanding that this was one of the 
> distinguishing points between the Code of Conduct/Proctors 
> and the existing Devrel structure.

Perhaps we shouldn't lump the CoC and Proctors together during this
discussion as those are two separate issues. I interpret the real issue to
be what is the policy and how would we like it enforced. That issue could
later lead into a discussion of forming a new team if that is ultimately
what we decide we simply must do.

> It seems rather clear to me, at any rate, that the Code of Conduct is
> normative:  It lays out in general terms boundaries for acceptable 
> *real time* behavior in the various Gentoo communications media.  
> I would consider this to be "active" control.
> Contrast this with ... "Developer relations should only be 
> involved in a conflict when other attempts to 
> solve the issue have failed."   
> I would consider this to be "passive" control.
> 
> Now, Council might not like it that way, but in my opinion (I 
> speak for myself here), we must live with the policy as it 
> reads, not as how we might like it to read.  

I have a slightly different view. We are not 'stuck' with policy as it is.
We have every opportunity to change policy as we grow and our needs change.
So, existing policy need not hold us back from updating policy and
implementing new ones.

> I have always been involved with Conflicts 
> Resolution and prefer to work as a mediator; I have little 
> interest in "policing" mailing lists or IRC.

I'd consider this to be an internal Dev Rel/Conf Res discussion. If someone
doesn't want to pursue all angles that a team operates in, then they should
have that discussion with the appropriate lead, though I doubt it would be
viewed as a problem in this case.
 
> > We don't need a new project to continue this sort of 
> > activity, nor do we need to add to the scope of any existing project.
> > Anyone can do it anytime. Curbing the worst excesses of friends is one 
> > of the things we can all do for one another. Continued poor behavior 
> > should be referred to the appropriate body in the normal way.
> > 
> I think it's [ML] calmed down, too.  I'll note that at the moment, 
> from what I've seen, Devrel (Conflicts) is getting very 
> little "action" as well.

I think the mailing list has calmed down in part due to the additional
mailing lists created and the purposes behind them. We have given
appropriate channels for most conversations. I also agree with Neddy when he
mentioned that each of us can help 'curb the worse excesses' of each other
and doing so in a civil manner. It seems to me that we have been doing that
well as of late.

> I'll use this as a vehicle to throw some oil onto the fire.  
> There seems to be a consensus for folding the old Proctor 
> function into Devrel/Userrel.  Of course, this has some 
> implications:  Devrel, for example, is structured to support 
> it's policy as it is now.  We can fold the Proctor function 
> into Devrel/Userrel, of course, but this has both staffing 
> implications and inter-group interaction implications.

These are points to note for sure, however I don't feel that they are severe
issues that should restrict us from doing so. Staffing needs: well those are
on going and in many teams, the additional work load as been nominal as
fmccor mentioned above. "(Conflicts) is getting very little "action" as
well." Inter-group interaction implications: I presume this is referring to
Dev Rel and User Rel working together. I don't see this as being a problem
in any way as we already work with those same people, in some cases they
hold roles on both teams.

> Personally, I think we'd end up establishing the Proctors by 
> another name.  What is the argument against just 
> reestablishing the Proctors and be done with it?  

I do not think we have indicated the *need* for Proctors specifically, or to
form any team by an name for the purpose of enforcing the CoC. So there is
no need to argue against something that has no argument to exist... if that
makes sense. ;-)

So to bring this back around to its originating points:
>	- how to enforce it
>		- whether it's active or passive enforcement
>		- which actions are appropriate

Anyone care to comment on what is appropriate? I think slong is the only one
who has touched on this portion:

> IMO muting a thread/locking a forum post/setting irc +m for 24 
> hours/forever/however long the ops think it needs, with 
> email/privmsg/pm discussion with whichever people are most 
> vociferously flaming each other (as decided by the mods.)

>	- who enforces it
>		- musikc said devrel could
>		- tsunam said userrel could

This is biased, obviously, but I agree with myself: Dev Rel and User Rel
could continue to handle this and update our documents/policies/etc to
indicate such.

> - If the -project list does not come up with a draft, dberkholz will 

I suspect dberkholz may end up writing the draft since he pre-volunteered,
but we should give him our opinions to be weighed into the matter so speak
up folks.

Kind regards,
Christina Fullam
Gentoo Developer Relations Lead | Gentoo Public Relations 



-- 
gentoo-project@gentoo.org mailing list

[gentoo-project] RE: CoC round 2 (or is it 10? ;)

[Steve Long]

Chrissy Fullam wrote:
> Perhaps we shouldn't lump the CoC and Proctors together during this
> discussion as those are two separate issues. I interpret the real issue to
> be what is the policy and how would we like it enforced. That issue could
> later lead into a discussion of forming a new team if that is ultimately
> what we decide we simply must do.
>
Thing is, what you imply there is a long drawn-out process, of deciding:
a) what are the issues?
b) what range of options are available?
c) what is the consensus on the best available options?

With respect, all this has already been discussed at _great_ length on the
dev list. The consensus was the CoC (which many felt was redundant since it
only reiterated the principles of extant policy) and the proctors to
enforce, similarly to the excellent job done by the forum mods.

I remind everyone that the forums are for many users the reason we stay with
Gentoo and, afaic, the envy of every other software project.

>> It seems rather clear to me, at any rate, that the Code of Conduct is
>> normative:  It lays out in general terms boundaries for acceptable
>> *real time* behavior in the various Gentoo communications media.
>> I would consider this to be "active" control.
Agreed.

> We are not 'stuck' with policy as it is.
> We have every opportunity to change policy as we grow and our needs
> change. So, existing policy need not hold us back from updating policy and
> implementing new ones.
>
How about implementing the ones we already have and then worrying about new
ones?

>> I have always been involved with Conflicts
>> Resolution and prefer to work as a mediator; I have little
>> interest in "policing" mailing lists or IRC.
> 
> I'd consider this to be an internal Dev Rel/Conf Res discussion. If
> someone doesn't want to pursue all angles that a team operates in, then
> they should have that discussion with the appropriate lead, though I doubt
> it would be viewed as a problem in this case.
>
Eh? I thought this was a discussion open to all? It's not part of devrel's
remit yet, so why on Earth would he raise it with that team? IMO that'd be
inappropriate (unless it were simply discussing the proposal, and that he
is at liberty to do via any medium, since it is not internal.)

No offense, but your statement smacks of authoritarianism. (I figure you're
grown-up enough for me to state that without you throwing a hissy fit.)

> I think the mailing list has calmed down in part due to the additional
> mailing lists created and the purposes behind them. We have given
> appropriate channels for most conversations. I also agree with Neddy when
> he mentioned that each of us can help 'curb the worse excesses' of each
> other and doing so in a civil manner. It seems to me that we have been
> doing that well as of late.
>
Neddy also pointed out that it was the summer vacation. I agree it's much
cooler now, though, especially since the commit reviews started appearing.
It's focussed minds wonderfully since devs now know any problems with their
ebuilds will be discussed on the m-l, "leveraging the eyeballs that is the
hallmark of Open-Source?" ;-)
 
>> I'll use this as a vehicle to throw some oil onto the fire.
>> There seems to be a consensus for folding the old Proctor
>> function into Devrel/Userrel.  Of course, this has some
>> implications:  Devrel, for example, is structured to support
>> it's policy as it is now.  We can fold the Proctor function
>> into Devrel/Userrel, of course, but this has both staffing
>> implications and inter-group interaction implications.
> 
> These are points to note for sure, however I don't feel that they are
> severe issues that should restrict us from doing so. Staffing needs: well
> those are on going and in many teams, the additional work load as been
> nominal as fmccor mentioned above. "(Conflicts) is getting very little
> "action" as well." Inter-group interaction implications: I presume this is
> referring to Dev Rel and User Rel working together. I don't see this as
> being a problem in any way as we already work with those same people, in
> some cases they hold roles on both teams.
>
Since the function is radically different, how about having a new team
including forum mods, with all devrel and userrel members automatically
having membership? That way the role (and function) is clearly demarcated,
so that people know exactly which set of policies are being followed, when.

>> Personally, I think we'd end up establishing the Proctors by
>> another name.  What is the argument against just
>> reestablishing the Proctors and be done with it?
> 
> I do not think we have indicated the *need* for Proctors specifically, or
> to form any team by an name for the purpose of enforcing the CoC. So there
> is no need to argue against something that has no argument to exist... if
> that makes sense. ;-)
>
Not really, since you said there is a function which devrel and userrel can
take on. Clearly it exists, and is novel.

As for the need, that was established by consensus over several months.
 
>>- who enforces it
>>- musikc said devrel could
>>- tsunam said userrel could
> 
> This is biased, obviously, but I agree with myself: Dev Rel and User Rel
> could continue to handle this and update our documents/policies/etc to
> indicate such.
>
Problem is you're basically saying it'll be the existing people whose roles
were supposed to cover this (since there is no new function, according to
the above.) That doesn't mean those people can't cover it, but speaking as
a user who has been caught on the wrong side of the herd, I don't actually
have much confidence in the existing core devs policing themselves. They
didn't do so well with maintaining the dev m-l for some years according to
the archives. Let's face it: they're devs, not moderators ;-)

>> - If the -project list does not come up with a draft, dberkholz will
> 
> I suspect dberkholz may end up writing the draft since he pre-volunteered,
> but we should give him our opinions to be weighed into the matter so speak
> up folks.
> 
Yeah where is everyone? It's not like cokehabit to keep his trap shut..
/me runs from the master of the verbal lash ;P


-- 
gentoo-project@gentoo.org mailing list