1 |
I hate long emails so I apologize in advance. Most of this is just showing |
2 |
what I base my own comments on in the hope that it makes more sense that |
3 |
way. :) |
4 |
|
5 |
|
6 |
> > How are passive and active defined in this context then? |
7 |
> > Passive would have to be the controllers wait for a complaint |
8 |
> > active would be the controllers work in as close to real time. |
9 |
> |
10 |
> It was my understanding that this was one of the |
11 |
> distinguishing points between the Code of Conduct/Proctors |
12 |
> and the existing Devrel structure. |
13 |
|
14 |
Perhaps we shouldn't lump the CoC and Proctors together during this |
15 |
discussion as those are two separate issues. I interpret the real issue to |
16 |
be what is the policy and how would we like it enforced. That issue could |
17 |
later lead into a discussion of forming a new team if that is ultimately |
18 |
what we decide we simply must do. |
19 |
|
20 |
> It seems rather clear to me, at any rate, that the Code of Conduct is |
21 |
> normative: It lays out in general terms boundaries for acceptable |
22 |
> *real time* behavior in the various Gentoo communications media. |
23 |
> I would consider this to be "active" control. |
24 |
> Contrast this with ... "Developer relations should only be |
25 |
> involved in a conflict when other attempts to |
26 |
> solve the issue have failed." |
27 |
> I would consider this to be "passive" control. |
28 |
> |
29 |
> Now, Council might not like it that way, but in my opinion (I |
30 |
> speak for myself here), we must live with the policy as it |
31 |
> reads, not as how we might like it to read. |
32 |
|
33 |
I have a slightly different view. We are not 'stuck' with policy as it is. |
34 |
We have every opportunity to change policy as we grow and our needs change. |
35 |
So, existing policy need not hold us back from updating policy and |
36 |
implementing new ones. |
37 |
|
38 |
> I have always been involved with Conflicts |
39 |
> Resolution and prefer to work as a mediator; I have little |
40 |
> interest in "policing" mailing lists or IRC. |
41 |
|
42 |
I'd consider this to be an internal Dev Rel/Conf Res discussion. If someone |
43 |
doesn't want to pursue all angles that a team operates in, then they should |
44 |
have that discussion with the appropriate lead, though I doubt it would be |
45 |
viewed as a problem in this case. |
46 |
|
47 |
> > We don't need a new project to continue this sort of |
48 |
> > activity, nor do we need to add to the scope of any existing project. |
49 |
> > Anyone can do it anytime. Curbing the worst excesses of friends is one |
50 |
> > of the things we can all do for one another. Continued poor behavior |
51 |
> > should be referred to the appropriate body in the normal way. |
52 |
> > |
53 |
> I think it's [ML] calmed down, too. I'll note that at the moment, |
54 |
> from what I've seen, Devrel (Conflicts) is getting very |
55 |
> little "action" as well. |
56 |
|
57 |
I think the mailing list has calmed down in part due to the additional |
58 |
mailing lists created and the purposes behind them. We have given |
59 |
appropriate channels for most conversations. I also agree with Neddy when he |
60 |
mentioned that each of us can help 'curb the worse excesses' of each other |
61 |
and doing so in a civil manner. It seems to me that we have been doing that |
62 |
well as of late. |
63 |
|
64 |
> I'll use this as a vehicle to throw some oil onto the fire. |
65 |
> There seems to be a consensus for folding the old Proctor |
66 |
> function into Devrel/Userrel. Of course, this has some |
67 |
> implications: Devrel, for example, is structured to support |
68 |
> it's policy as it is now. We can fold the Proctor function |
69 |
> into Devrel/Userrel, of course, but this has both staffing |
70 |
> implications and inter-group interaction implications. |
71 |
|
72 |
These are points to note for sure, however I don't feel that they are severe |
73 |
issues that should restrict us from doing so. Staffing needs: well those are |
74 |
on going and in many teams, the additional work load as been nominal as |
75 |
fmccor mentioned above. "(Conflicts) is getting very little "action" as |
76 |
well." Inter-group interaction implications: I presume this is referring to |
77 |
Dev Rel and User Rel working together. I don't see this as being a problem |
78 |
in any way as we already work with those same people, in some cases they |
79 |
hold roles on both teams. |
80 |
|
81 |
> Personally, I think we'd end up establishing the Proctors by |
82 |
> another name. What is the argument against just |
83 |
> reestablishing the Proctors and be done with it? |
84 |
|
85 |
I do not think we have indicated the *need* for Proctors specifically, or to |
86 |
form any team by an name for the purpose of enforcing the CoC. So there is |
87 |
no need to argue against something that has no argument to exist... if that |
88 |
makes sense. ;-) |
89 |
|
90 |
So to bring this back around to its originating points: |
91 |
> - how to enforce it |
92 |
> - whether it's active or passive enforcement |
93 |
> - which actions are appropriate |
94 |
|
95 |
Anyone care to comment on what is appropriate? I think slong is the only one |
96 |
who has touched on this portion: |
97 |
|
98 |
> IMO muting a thread/locking a forum post/setting irc +m for 24 |
99 |
> hours/forever/however long the ops think it needs, with |
100 |
> email/privmsg/pm discussion with whichever people are most |
101 |
> vociferously flaming each other (as decided by the mods.) |
102 |
|
103 |
> - who enforces it |
104 |
> - musikc said devrel could |
105 |
> - tsunam said userrel could |
106 |
|
107 |
This is biased, obviously, but I agree with myself: Dev Rel and User Rel |
108 |
could continue to handle this and update our documents/policies/etc to |
109 |
indicate such. |
110 |
|
111 |
> - If the -project list does not come up with a draft, dberkholz will |
112 |
|
113 |
I suspect dberkholz may end up writing the draft since he pre-volunteered, |
114 |
but we should give him our opinions to be weighed into the matter so speak |
115 |
up folks. |
116 |
|
117 |
Kind regards, |
118 |
Christina Fullam |
119 |
Gentoo Developer Relations Lead | Gentoo Public Relations |
120 |
|
121 |
|
122 |
|
123 |
-- |
124 |
gentoo-project@g.o mailing list |