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.
> 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
>> 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
firstname.lastname@example.org mailing list