Gentoo Archives: gentoo-project

From: Steve Long <slong@××××××××××××××××××.uk>
To: gentoo-project@l.g.o
Subject: [gentoo-project] RE: CoC round 2 (or is it 10? ;)
Date: Sat, 20 Oct 2007 01:37:41
Message-Id: ffblg3$rl$1@ger.gmane.org
In Reply to: RE: [gentoo-project] CoC round 2 (or is it 10? ;) by Chrissy Fullam
1 Chrissy Fullam wrote:
2 > Perhaps we shouldn't lump the CoC and Proctors together during this
3 > discussion as those are two separate issues. I interpret the real issue to
4 > be what is the policy and how would we like it enforced. That issue could
5 > later lead into a discussion of forming a new team if that is ultimately
6 > what we decide we simply must do.
7 >
8 Thing is, what you imply there is a long drawn-out process, of deciding:
9 a) what are the issues?
10 b) what range of options are available?
11 c) what is the consensus on the best available options?
12
13 With respect, all this has already been discussed at _great_ length on the
14 dev list. The consensus was the CoC (which many felt was redundant since it
15 only reiterated the principles of extant policy) and the proctors to
16 enforce, similarly to the excellent job done by the forum mods.
17
18 I remind everyone that the forums are for many users the reason we stay with
19 Gentoo and, afaic, the envy of every other software project.
20
21 >> It seems rather clear to me, at any rate, that the Code of Conduct is
22 >> normative: It lays out in general terms boundaries for acceptable
23 >> *real time* behavior in the various Gentoo communications media.
24 >> I would consider this to be "active" control.
25 Agreed.
26
27 > We are not 'stuck' with policy as it is.
28 > We have every opportunity to change policy as we grow and our needs
29 > change. So, existing policy need not hold us back from updating policy and
30 > implementing new ones.
31 >
32 How about implementing the ones we already have and then worrying about new
33 ones?
34
35 >> I have always been involved with Conflicts
36 >> Resolution and prefer to work as a mediator; I have little
37 >> interest in "policing" mailing lists or IRC.
38 >
39 > I'd consider this to be an internal Dev Rel/Conf Res discussion. If
40 > someone doesn't want to pursue all angles that a team operates in, then
41 > they should have that discussion with the appropriate lead, though I doubt
42 > it would be viewed as a problem in this case.
43 >
44 Eh? I thought this was a discussion open to all? It's not part of devrel's
45 remit yet, so why on Earth would he raise it with that team? IMO that'd be
46 inappropriate (unless it were simply discussing the proposal, and that he
47 is at liberty to do via any medium, since it is not internal.)
48
49 No offense, but your statement smacks of authoritarianism. (I figure you're
50 grown-up enough for me to state that without you throwing a hissy fit.)
51
52 > I think the mailing list has calmed down in part due to the additional
53 > mailing lists created and the purposes behind them. We have given
54 > appropriate channels for most conversations. I also agree with Neddy when
55 > he mentioned that each of us can help 'curb the worse excesses' of each
56 > other and doing so in a civil manner. It seems to me that we have been
57 > doing that well as of late.
58 >
59 Neddy also pointed out that it was the summer vacation. I agree it's much
60 cooler now, though, especially since the commit reviews started appearing.
61 It's focussed minds wonderfully since devs now know any problems with their
62 ebuilds will be discussed on the m-l, "leveraging the eyeballs that is the
63 hallmark of Open-Source?" ;-)
64
65 >> I'll use this as a vehicle to throw some oil onto the fire.
66 >> There seems to be a consensus for folding the old Proctor
67 >> function into Devrel/Userrel. Of course, this has some
68 >> implications: Devrel, for example, is structured to support
69 >> it's policy as it is now. We can fold the Proctor function
70 >> into Devrel/Userrel, of course, but this has both staffing
71 >> implications and inter-group interaction implications.
72 >
73 > These are points to note for sure, however I don't feel that they are
74 > severe issues that should restrict us from doing so. Staffing needs: well
75 > those are on going and in many teams, the additional work load as been
76 > nominal as fmccor mentioned above. "(Conflicts) is getting very little
77 > "action" as well." Inter-group interaction implications: I presume this is
78 > referring to Dev Rel and User Rel working together. I don't see this as
79 > being a problem in any way as we already work with those same people, in
80 > some cases they hold roles on both teams.
81 >
82 Since the function is radically different, how about having a new team
83 including forum mods, with all devrel and userrel members automatically
84 having membership? That way the role (and function) is clearly demarcated,
85 so that people know exactly which set of policies are being followed, when.
86
87 >> Personally, I think we'd end up establishing the Proctors by
88 >> another name. What is the argument against just
89 >> reestablishing the Proctors and be done with it?
90 >
91 > I do not think we have indicated the *need* for Proctors specifically, or
92 > to form any team by an name for the purpose of enforcing the CoC. So there
93 > is no need to argue against something that has no argument to exist... if
94 > that makes sense. ;-)
95 >
96 Not really, since you said there is a function which devrel and userrel can
97 take on. Clearly it exists, and is novel.
98
99 As for the need, that was established by consensus over several months.
100
101 >>- who enforces it
102 >>- musikc said devrel could
103 >>- tsunam said userrel could
104 >
105 > This is biased, obviously, but I agree with myself: Dev Rel and User Rel
106 > could continue to handle this and update our documents/policies/etc to
107 > indicate such.
108 >
109 Problem is you're basically saying it'll be the existing people whose roles
110 were supposed to cover this (since there is no new function, according to
111 the above.) That doesn't mean those people can't cover it, but speaking as
112 a user who has been caught on the wrong side of the herd, I don't actually
113 have much confidence in the existing core devs policing themselves. They
114 didn't do so well with maintaining the dev m-l for some years according to
115 the archives. Let's face it: they're devs, not moderators ;-)
116
117 >> - If the -project list does not come up with a draft, dberkholz will
118 >
119 > I suspect dberkholz may end up writing the draft since he pre-volunteered,
120 > but we should give him our opinions to be weighed into the matter so speak
121 > up folks.
122 >
123 Yeah where is everyone? It's not like cokehabit to keep his trap shut..
124 /me runs from the master of the verbal lash ;P
125
126
127 --
128 gentoo-project@g.o mailing list