1 |
Please note that in what follows I speak only for myself, but from the |
2 |
perspective of a Devrel member concerned with Conflicts Resolution. I |
3 |
explicitly do not speak for Devrel, nor have I reviewed what I say with |
4 |
anyone in Devrel. |
5 |
|
6 |
On Mon, 2007-10-15 at 17:22 +0100, Roy Bamford wrote: |
7 |
> On 2007.10.14 13:39, Steve Long wrote: |
8 |
|
9 |
=== Large snip === |
10 |
|
11 |
> Steve, |
12 |
> |
13 |
> Some interesting points ... control of any written channel can only be |
14 |
> passive, in the sense that controllers are always responding after the |
15 |
> event. The possible exception is a moderated mailing list. |
16 |
> |
17 |
> How are passive and active defined in this context then? |
18 |
> Passive would have to be the controllers wait for a complaint before |
19 |
> acting and active would be the controllers work in as close to real |
20 |
> time as the medium allows, on things they notice for themselves as |
21 |
> happens in IRC and forums. They are always reactive regardless. |
22 |
|
23 |
It was my understanding that this was one of the distinguishing points |
24 |
between the Code of Conduct/Proctors and the existing Devrel structure. |
25 |
It seems rather clear to me, at any rate, that the Code of Conduct is |
26 |
normative: It lays out in general terms boundaries for acceptable *real |
27 |
time* behavior in the various Gentoo communications media. The |
28 |
Proctors, I believe, were established as a policing body for this |
29 |
(recall my "traffic cop" analogy; I think it holds up). I would |
30 |
consider this to be "active" control. |
31 |
|
32 |
Contrast this with how Devrel policy reads. Devrel policy is pretty |
33 |
clear; to quote from Policy, "Developer relations should only be |
34 |
involved in a conflict when other attempts to solve the issue have |
35 |
failed." Thus, except in extreme situations, by current policy Devrel |
36 |
is explicitly NOT a "traffic cop." Devrel takes official notice when |
37 |
someone "rings our bell" (to quote from IRC --- it's an in-joke). I |
38 |
would consider this to be "passive" control. |
39 |
|
40 |
Now, Council might not like it that way, but in my opinion (I speak for |
41 |
myself here), we must live with the policy as it reads, not as how we |
42 |
might like it to read. And, again speaking for myself again, I think |
43 |
composition of Devrel reflects that: I have always been involved with |
44 |
Conflicts Resolution and prefer to work as a mediator; I have little |
45 |
interest in "policing" mailing lists or IRC. |
46 |
|
47 |
> Most of the proctors actions were carried out in private, this seemed |
48 |
> to work best since most people hate to be publicly asked to exercise |
49 |
> restraint. We don't need a new project to continue this sort of |
50 |
> activity, nor do we need to add to the scope of any existing project. |
51 |
> Anyone can do it anytime. Curbing the worst excesses of friends is one |
52 |
> of the things we can all do for one another. Continued poor behavior |
53 |
> should be referred to the appropriate body in the normal way. |
54 |
> |
55 |
Absolutely. I'll metion that Devrel mediations are of necessity private |
56 |
as well. A mediator holds a position of trust, and implicit in that is |
57 |
that the mediator will not post private conversations will not on |
58 |
bulletin boards. As for the rest of the statement, all I can do is |
59 |
concur. |
60 |
|
61 |
> The -dev mailing list seems to have calmed down since the proctors most |
62 |
> public action, when a number of users had their posting rights |
63 |
> suspended briefly. I'm unsure if the creation of -project played a big |
64 |
> part in this or not. Judging by the number of posts to -project, I |
65 |
> think its unlikely. I'm more inclined to believe that the bloodletting |
66 |
> on that particular thread was something that everyone was aware of |
67 |
> and nobody wanted to risk repeating. Thus the proctors served their |
68 |
> purpose. |
69 |
|
70 |
I think it's calmed down, too. I'll note that at the moment, from what |
71 |
I've seen, Devrel (Conflicts) is getting very little "action" as well. |
72 |
|
73 |
I'll use this as a vehicle to throw some oil onto the fire. There seems |
74 |
to be a consensus for folding the old Proctor function into |
75 |
Devrel/Userrel. Of course, this has some implications: Devrel, for |
76 |
example, is structured to support it's policy as it is now. We can fold |
77 |
the Proctor function into Devrel/Userrel, of course, but this has both |
78 |
staffing implications and inter-group interaction implications. |
79 |
Personally, I think we'd end up establishing the Proctors by another |
80 |
name. What is the argument against just reestablishing the Proctors and |
81 |
be done with it? Experience shows that however we do it, there will be |
82 |
start-up problems as both the Code of Conduct comes better into focus |
83 |
and people play with what does work and what does not. And |
84 |
responsibility for the function should not lie with Council: we are |
85 |
talking about a Gentoo Project (perhaps in Devrel/Userrel) meant to last |
86 |
longer than any specific Council. Like it or not, individual Councils |
87 |
are short term. |
88 |
|
89 |
As Roy points out above, we actually do not need the Proctors by any |
90 |
name if the community in general polices itself effectively. Indeed, |
91 |
one of my goals as a Devrel mediator, or anyone's goals working in a |
92 |
policing function, must be to establish an environment where the |
93 |
function itself becomes unnecessary. I am not sure this is achievable, |
94 |
but thus the ongoing discussion of Code of Conduct. |
95 |
|
96 |
> Regards, |
97 |
> |
98 |
> Roy Bamford |
99 |
> (NeddySeagoon) |
100 |
> Is/was a member of |
101 |
> gentoo-forums |
102 |
> gentoo-ops |
103 |
> gentoo-treecleaners |
104 |
> gentoo-proctors |
105 |
> |
106 |
As always, comments, questions, suggestions welcome. Feel free to keep |
107 |
pure flames to yourself. :) |
108 |
|
109 |
Regards, |
110 |
-- |
111 |
Ferris McCormick (P44646, MI) <fmccor@g.o> |
112 |
Developer, Gentoo Linux (Devrel, Sparc) |