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 |