1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
\chapter{Code of Conduct}
\section{``CoC enforcement proposal'', by Donnie Berkholz, Nov. 2007}
\label{2007-11-dberkholz-coc}
Source: \agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979}
\index{Code of Conduct!enforcement}\index{project!proctors}
\index{developer!dberkholz}
\vspace*{1cm}
Consider this entire document a draft open to council discussion. I
appreciate the people on the gentoo-project list who contributed to the
discussion.
\paragraph{The problem}
My basic philosophy is: compliment in public, criticize in private. One
of the problems with the proctors last time around was that their
actions became too public, embarrassing the parties involved. Another
problem with the proctors was that real action was not taken soon
enough, and too long was spent talking. Real action in this context
means that someone is temporarily blocked from posting to the relevant
forum (mailing lists, IRC, forums), rather than sitting around talking.
A third problem with the proctors was the difference in interpretation
of the CoC within the group and with the council. It's particularly
important to discriminate technical discussions from personal attacks
and misconduct.
\paragraph{The conceptual solution}
A primary focus of CoC enforcement is deterrence from continued
violation, so permanent action is unnecessary. Thus, what seems
necessary is a way to take rapid, private, temporary action.
By making initial actions temporary (e.g., 6-12 hours in most cases),
they can be taken rapidly with little negative consequence in the case
of a mistake. The goal is to provide developers with a cooling-off
period but allow them to rejoin the discussion with little loss. Since
the actions are always private, the only reason other developers will
learn about them is that either the affected developer or whoever took
the action (the actor) leaked it. Leaks by the actor will be taken
seriously as a CoC violation in their own right.
The basic idea behind the time frame is that the longer the action, the
fewer people who can choose to take it. Perhaps only one or two people
besides the council could decide to take any action longer than 12
hours, which would severely impede a developer's ability to participate
in a discussion.
Whoever's taking action also needs to have a similar interpretation of
the CoC as the council, which is the problem that came up with the
proctors. To ensure this, the council will need some kind of role in
deciding who could take action. But we don't want to fall into the trap
of writing down every little rule and every possible infraction; that
just makes it easy to find loopholes.
\paragraph{The implementation}
One way to enable Gentoo to enforce the CoC with these ideas in mind is
to create a highly selective team with only short-term abilities and a
strong lead to ensure the team's actions fit the council's CoC
interpretation. Adhering to the principles mentioned above is what
discriminates between this group and the former proctors.
All this team's actions must be approved by the lead within a short time
period or must be reverted. It's expected that many actions will range
from 6-12 hours, so 12 hours seems like a reasonable time to require
lead approval. Whenever the lead is unavailable, approval falls to the
council. (Remember, two council members together can make decisions.)
The lead of this team must gain council approval for any action lasting
3 or more days. To ensure that this process remains temporary, in no
case can any action last longer than 7 days. These actions must also be
forwarded on to devrel or userrel, depending on who's involved, and they
will consider longer-term suspension or termination.
There is no conflict of interest between the council and this team's
members, because the council is considered to have the best interests of
Gentoo in mind. Developers can be members of both groups. The council
must approve all members of this team, and it must reassess them
annually to ensure they still interpret the CoC in the same way.
Furthermore, the team's lead will be appointed by the council to further
ensure a cohesive CoC interpretation.
It is expected that membership on this team will be highly selective and
not all who wish to join will make the cut. The team will be limited to
3 people for a probationary period so we don't get dumped in the deep
end right away, and it will never have more than 5 people. Once
appointed by the council, the team lead will choose applicants for the
rest of the team to forward on for council approval.
|
GitWeb