On 13:12 Thu 08 Nov , Ferris McCormick wrote:
> This is a big step forward, and if we had a binary situation: either
> accept it as written or go back to the drawing board, I'd prefer to
> accept. Thus my comments which follow are best viewed as requests for
> clarification or of personal inclination.
Thanks for your comments, and I want to reiterate that we certainly do
not have a binary situation in that respect. What we do have is
preliminary text that could use suggestions like yours. =)
> 1. Are 3 (or 5) people sufficient to ensure quick reactions to mailing
> list questions or IRC? This is minor, and starting with 3 to put the
> process in place and tune it as needed probably works. My concern is
> longer term. Speaking for myself, for instance, I almost never see
> problems on IRC until they are long over, and I suspect this is the case
> for most people. Similarly (usually) with mail. And I don't think we
> want a corps of full-time monitors.
I understand your point, which amne also brought up. My main concerns
with a larger group are that it will be unable to maintain a cohesive
view of the CoC and that anyone who feels like it can join up.
> 2. As to forums, I've never seen that the forum moderators need any
> help with what they are doing. Actually, in a sense I think the forums
> are kind of a model for what you are proposing.
I agree. Should we add a note that already-moderated places (#gentoo,
forums) should not need additional moderation?
> 3. I note that most actions are very short term, so if things are
> working as they should, the lead (or council) will seldom or never get
> involved in the day to day process. I think this is a huge plus for
> your proposal!
Yep, it's hard to act quickly if you're sitting around waiting for a
lead in another time zone to show up.
> 4. I learned from talking to some of the proctors that they did
> generally work in private. It would be useful perhaps to see how
> closely the bulk of what they did conformed to your proposal (as opposed
> to how previous Council perceived them). And of course where it
> diverged. (I am addressing the last sentence of the first paragraph of
> the "implementation" section here, and just raising a question.)
I would also enjoy hearing from past proctors. From my POV, where things
started to fall apart is where they started (a) acting publicly and (b)
dropping to the level of those they should be taking action against.
> 5. Do you perceive the enforcement group as an arm of the Council
> rather than as a group of its own? Previously, the Council did not seem
> to know what to do when the Proctors' views of Code of Conduct and
> Councils' *individual* views of Code of Conduct seemed to diverge. This
> led to the unusual step of simply eliminating the Proctors. I rather
> doubt that you would find much enthusiasm for working in such an
> environment again. So, what you are proposing probably works for any
> given Council (assuming continuing commitment from council to council).
> I think my concern is addressed to (a) continuing commitment; (b)
> consistency and continuity. The Gentoo community need to understand the
> rules so that they become a part of our culture, so that even with
> annual assessment, we should expect evolution rather than catastrophe.
> (This was all a bit muddled. That's sure indication that so are my
> thoughts, so take it for what it's worth.)
> 6. "Developers can be members of both [Council and Code of Conduct
> team]." This is the one sentence I take exception to. It's better to
> work for more community involvement rather than allow concentration
> resulting in personnel wearing multiple hats.
The above two points tie together, in my mind. It would be preferable to
have at least one of the team members be on council to ensure that their
CoC interpretations are consistent.
That gave me a new idea. What if the first 2-4 weeks, the team did not
actually take any action but just documented what its actions would have
been? This would give people a feeling for what level of enforcement
we'd see for the CoC.
> 7. Off the top of my head, why not allow (or require) that one member
> of the team be a user but not a developer? Userrel, all, comments?
If we could find a user with a strong enough grasp of Gentoo culture,
I'm open to the idea, and I'd like to make any users adjunct staff
members during their term to avoid that annoying "Users don't have power
over me" syndrome.
email@example.com mailing list