[gentoo-dev] Re: Introducing the Proctors - Draft Code of Conduct for Gentoo

[Duncan]

Grant Goodyear <g2boojum@g.o> posted
20070314002523.GC12689@××××××××××××××××××××××××.com, excerpted below, on 
Tue, 13 Mar 2007 19:25:23 -0500:

> Robin H. Johnson wrote: [Tue Mar 13 2007, 06:05:10PM CDT]
>> On Tue, Mar 13, 2007 at 04:09:53PM -0500, Grant Goodyear wrote:
>> > * Can we find a better name than "the Proctors", please?
>>
>> Suggestions welcome. We were stuck for other suitable names, and it was
>> my own suggestion for proctors, based on the dictionary definition: "an
>> official charged with various duties, esp. with the maintenance of good
>> order." [1]
>
> Ubuntu uses "Community Council".  I suggested "Community Relations".

[I'm replying here as this subthread most directly addresses the concerns 
I too have, but I'll reference other threadlets as well.]

"Procter" seems the precise dictionary definition of what I believe we 
are after, but if people aren't familiar with it, as seems to be the 
case...

Someone suggested "Communication's Supervisor", which should be simple 
enough but might be confused with parts of infra.  What about "Gentoo 
Communications Representative" (tho that sounds like userrel/devrel)?  
Or, getting the authority in there, "Gentoo Council Communications Envoy"?

>> > * I highly recommend reading http://www.ubuntu.com/community/conduct
>> >   and our new doc side-by-side.  The former provides strong, positive
>> The Ubuntu guidelines are well-mirrored in the existing etiquette
>> policy:
>> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?
part=3&chap=2
>
> One may argue with the content of either the old etiquette guide or the
> Ubuntu Code of Conduct, but I suspect that most would agree that the
> Ubuntu Code of Conduct is both more encouraging and better written. I
> think it's also much more encouraging and better written than is the
> proposed doc, as well.

I agree.  Regardless of the content and tone, which can be argued, the 
Ubuntu CoC has things in a clear and logical order, making clear the goal 
before describing the behavior, then describing behavior that matches 
that goal, then describing certain behavior that does /not/ match the 
goal and is therefore discouraged.  Finally, the authority and who is 
responsible for enforcing the policy is noted.

One other point.  It's quite clear throughout the Ubuntu doc who is being 
referred to.  One of the big problems with the proposed Gentoo document 
IMO is that in its current form it uses the term "we" far too often, 
often even in the first sentence of a section, without noting who "we" is 
except at the top in broad terms (Gentoo).  Only the corporate whole 
"Gentoo" does not fit the usage of "we" in some instances all that well 
-- a more natural fit would be the enforcers (whatever they may be 
called) or perhaps the Council, and thus Gentoo thru it.

>> However the existing policy has not worked. Reasons and theories behind
>> why are rife within Gentoo.
>
> You're arguing that a much more punitive doc is required because the
> previous doc has been ineffective?  That's a reasonable argument, but I
> don't think I agree.  The previous doc had no "moral weight", so to
> speak, because it was imposed on devs without any real discussion, and
> that's made it hard to enforce.

I'd argue here a position I haven't yet seen... exactly.  IMO, there are/
were two problems with the current /developer/ etiquette policy.

First, it was both in the developer manual and by wording targeted 
specifically at developers.  Non-developer participants in the various 
communications channels likely will not have seen it, and where it was, 
it /was/ a bit easy to "forget" about, even for developers that /had/ 
seen it.  It wasn't as if it were channel communication policy, posted or 
linked prominently at the entry or in each location, so it was easy to 
"forget" (aka "ignore", if it were deliberate, but let's just assume it's 
not for now).

If it's more visible to everyone, and is generally accepted as applying 
to all, perhaps it'll be easier to "remember".

In line with that observation, a suggestion -- /only/ a suggestion, as 
I'm sure some won't like it, but I think it needs considered, anyway.  
Many web forums and IRC channels have a "sticky" guide or at minimum, a 
link to the rules, visible whenever one enters.  That's not so easy on 
mailing lists or newsgroups.  However, newsgroups at least have an 
accepted solution: a FAQ posted periodically (say biweekly or monthly).  
Many mailing lists have a subscription/unsubscribe/help reminder sent out 
periodically, so the idea isn't entirely foreign there either, altho 
posting of a (behavior) FAQ is a bit less common.  I think we seriously 
need to consider it.  We could in fact combine it with a periodic 
unsubscribe help mailing (which might eliminate a few of the occasional 
mixed up unsubscribe postings to the list, as well), since Gentoo 
controls its own mailing lists.

Second and I think more important, given it has been developers and 
former devs that have been the major problem, it wasn't the lack of teeth 
of the former /document/ that was the problem, but rather, a lack of 
means or will to enforce it, directly and in a timely manner as applied 
to the communications channels (this mailing list in particular, in this 
case).  Largely by deliberate design, the devrel discipline process is 
bureaucratic in nature and requires time, both to ideally enable a 
cooling off and avoid further dealing with the issue in the first place, 
and to ensure full due process.  While the degree of that can be argued, 
I think most here will agree that to /some/ degree it's a /good/ thing -- 
after all, we /are/ talking about possible termination of a dev, when it 
comes to devrel.

I believe the problem was that the by design slow process of dev 
discipline simply is not suited to resolution of the fast developing 
issues on the mailing lists (and the same may apply to other channels as 
well).  Yet we (Gentoo) were trying to make it work, and we are where we 
are as a result.

Thus, I don't believe a draconian document is called for.  It's not the 
content at fault, but the location and the enforcement "impedance 
mismatch".  Correct those, and the problem will be /much/ easier to 
correct as well.

>> >   [I agree] that a few days isn't really enough time for an adequate
>> >   discussion.  For this sort of policy to be effective, devs need to
>> >   agree with it.  The Council can still make temporary rules on
>> >   Thursday while allowing the rest of the process to occur more
>> >   leisurely.

>> As the council[, we are] saying that the buck stops here, because
>> right now, Gentoo is being seriously damaged as a distribution.
>
> I simply
> think you folks are rushing things more than is really necessary. Take a
> look at yesterday's threads started by Mr. Long.  He was stirring up
> trouble, and he was not terribly successful because, after a bit of
> latency, people refused to play along.  That's a positive change that I
> suspect occurred at least in part _because_ the Council is leading here.
>  I think the Council is already making a difference, and that there's
> time to come up with something beautiful instead of just functional.

I don't think it's the council yet.  I think it's still the "shell shock" 
speaking.  Nobody who went thru that wants to see anything like it again, 
certainly not now, so everyone's being especially cautious on the one 
hand, and on the other, like many air passengers today, we simply aren't 
going to play along any longer with potential hijackings, and they no 
longer tend to work.

I think the council's worry is two-fold.  First, Gentoo must be seen to 
have taken some action to stem the damage, or we'll lose even more 
credibility (and likely attract more trolls out for some fun... 
unfortunately).  Second, that post event watchfulness may not last 
forever, and the council wants something in place before it's gone.

Those are both very reasonable, but I too agree with you and others, the 
current draft just doesn't cut it as a long term document and if we try 
and force it to, we're likely to be dealing with some other crisis as a 
result some time down the road.

What I think may be the best that can be done under the circumstances is 
to adopt this document (as can be best modified in the next xx hours) as 
a say 40-day policy, auto-sunset, thus guaranteeing we aren't stuck with 
it beyond that term.  That then gives us the rest of the month to hash 
out a better document, hopefully to be adopted at the next regular 
council meeting, and a few days further to implement it in an orderly 
fashion before the temp policy expires.  If the permanent policy isn't 
ready by that time, the council can then extend the temp policy another 
30 days, and there should be little reason found to extend it yet again, 
as the permanent policy should have been hashed out by that point, or /
possibly/ after a bit of time, they/we might see a different, better 
approach, and not need either a further extension of the temp policy or 
implementation of a direct replacement.

>> > * Having a group of folks separate from devrel who would be doing
>> >   similar things to what devrel does (when devrel isn't involved in
>> >   recruiting) somehow seems a bit silly.  I'd much rather we just
>> >   broaden that part of Developer Relations to Community Relations.
>> I'd to quote from Christel's mail here: "2. The Proctors is not a new
>> name for Devrel. They would fall under Devrel territory, but as a newly
>> formed group under the leadership and supervision of the Council. A
>> decision as to numbers and electing proctors has not yet been reached
>> -- we are working out these details as we speak.
>
> *Grin* I actually did read Christel's e-mail.  I disagree with that
> part.

If my argument above is assumed to be correct, then it should be obvious 
that devrel in its current form isn't right for the task.  First, it's 
/dev/rel, and we are talking a communication channels policy applying to 
all users, including but not limited to devs.  Second, there's the timing 
thing.  Now, it might be possible to give them the power to act in 
appropriately short time here, while continuing the full due process 
procedure for questions of dev discipline (as opposed to comm channel 
discipline), but there's no reason it /has/ to be them, given the timing  
difference.  Additionally, we /are/ talking a policy applying to users as 
well, and I believe the idea of a wider community representation is sound 
in that regard.  By the same token, I honestly can't say whether devs 
will find it acceptable for a group with a significant non-dev component 
to be doing the devrel task, so it's really two widely different tasks, 
and I think it works best as two different groups.

By the same token, however, I don't see a problem if most or all of 
devrel end up as proctors.  However, I believe the groups should be 
independent, and likely, that "comrep" should be accountable directly to 
the council.

>> (My suggestion here is to select a group of people from a wide variety
>> of backgrounds within Gentoo, taking care to avoid 'old boys clubs' and
>> cliques)"
>>
>> Simply renaming devrel to commrel and handing them the task won't solve
>> anything - there will still be complaints that devrel is being unfair
>> (and is indeed why your Ombuds position exists). As the council, we
>> will require of the Proctors that they are impartial and fair.
>
> Here's my problem with it: essentially what you're arguing for the
> proctors to be is the same as what devrel should be (at least for the
> part of devrel that is supposed to be looking after community
> standards).

To me it's two different groups, two different tasks.  The one deals with 
developer relations, in the worst case leading to developer termination.  
That /should/ be a task that takes a bit of time, with additional due 
process protections built-in.  The other deals with community 
communications channels, in the worst case leading to permanent 
termination of voice in one or more of those channels.  While that has a 
direct significance for the dev's ability to properly do his work as a 
dev, user implications are much more muted.  

Additionally, I see a STRONG benefit in the ability of the "comrep" group 
to order a 3-day or 1 week cooling off period WITHOUT it directly 
interfering with devrel status.  In fact, one could claim that part of 
the paralysis in the current situation had to do with the fact that 
getting devrel involved was a BIG step, something folks often hesitated 
to do until too late.  If the two processes were independent of each 
other, a short term cooling off period of a few days would be MUCH more 
likely to be imposed if arguably necessary but not debateably borderline, 
as it wouldn't be such a drastic step in all those OTHER ways.  As such, 
weaker consequences earlier are likely to be imposed, hopefully avoiding 
the necessity of even /debating/ stronger consequences later, as /well/ 
as applying the brakes before anything like the debacle we recently 
witnessed happens again.

>> > * Ubuntu requires that their devs sign a copy of their code of
>> > conduct.

>> How do we enforce this on users (both those that were never developers
>> as well as those that were ex-developers) fairly then? I see equal
>> enforcement as a benefit here.
>
> One might argue that devs should be held to a slightly higher standard
> than the users.  My understanding is that w/ Ubuntu the devs sign the
> code because they are the standard bearers of the distribution.  Their
> views are going to hold more weight in the community because of that
> ubuntu.org e-mail address, and by signing the code they provide a good
> example for the users.  The users are expected to play by the same
> rules, but of course they don't have to sign anything; it's implicit by
> signing up on a mailing list (or forum, or whatever).
>
> *Shrug*  I don't really have a strong opinion about this last item.  I'm
> just trying to offer things to think about.

I agree, same rules, enforceable on all, but having devs sign (plus 
putting a question or two on the quiz dealing with such things, not 
because anyone will answer wrong, but because it'll bring the awareness 
up) increases their awareness of it in approximate degree to which their 
visibility as Gentoo representatives is increased.

The question then may come up, what happens if someone can't or doesn't 
wish to sign for some reason?  My opinion?  Again, it's an awareness 
thing.  By indicating they can't sign it, they've indicated that they are 
aware of it, and if the policy is that as a dev they will be held to it 
regardless of whether they signed or not, with their devship ultimately 
hanging in the balance if they disregard it, well, they then know that 
whether they choose to sign or not.  It's a signature of awareness, not 
of agreement, and choosing not to sign indicates the same thing.  The 
policy gets applied the same whether they sign or not.

Still, as the others, no strong opinion here, just opinion.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list