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
93
94
95
96
97
98
|
\summary{2007}{12}{13}
\agendaitem{New USE documentation}
\index{USE}\index{global changes}
Reference: http://archives.gentoo.org/gentoo-dev/msg_149120.xml (dead link)
Considering the precedent set by how this was implemented,
what should we do? Should we leave it or revert it? Should we require a GLEP?
Other options:
\begin{itemize}
\item Discuss improvements on -dev, make changes, document them.
In other words, normal development process
\item Leave as is
\item Require future global changes to be sent to -dev in advance,
or they will be reverted.
\end{itemize}
Result of the discussion:
\begin{enumerate}
\item
We're leaving it, and considering further changes
\item
It should have been posted to -dev before committing for discussion
\end{enumerate}
General process for global changes:
\begin{itemize}
\item
1. Post to -dev for discussion
\item
2a. Consensus for implementing your idea as-is. No GLEP, no council.
BREAK.
\item
2b. Consensus for a GLEP for your idea, maybe disagreement over the idea.
Write GLEP. Discuss on -dev. Submit GLEP to council.
\item
2c. Disagreement, but some support. No consensus for a GLEP. Respond to the
council agenda mail with a post containing a summary of your idea as
well as patches for code and documentation.
\item
2d. No support. Refine your idea, or think of a new one. GOTO 1.
\item
3. Council votes on the idea.
\end{itemize}
Any future global changes that aren't discussed on -dev in advance may
be reverted by the council if at least two council members vote to revert
the changes. Those changes must be discussed on -dev and approved by the
council before recommitting. If they're recommitted without council
approval, the developer in question gets kicked out.
\agendaitem{Code of Conduct enforcement}
\index{Code of Conduct}\index{mailing list!gentoo-dev}
\index{irc!channel!\#gentoo-dev}
References:
\begin{itemize}
\item
http://thread.gmane.org/gmane.linux.gentoo.council/82 (broken link)
\item
\url{http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt}
\end{itemize}
Christy Fullam (musikc) made some valuable suggestions:
\begin{itemize}
\item The proposal should be restricted to only apply to \#gentoo-dev and the
gentoo-dev list. Most other locations already have moderators of some
sort, and the council can work with them directly if there are CoC
problems. This idea went over really well.
\item Moderation should be capped at 2 days, and then will be handed off to
devrel/userrel. No council approval involved.
\end{itemize}
Mike Doty (kingtaco) suggested that we look for a way to prevent the
snowball effect on IRC: what if a modded person is voiced/opped by an
unmodded person, and a chain of this goes?
Donnie Berkholz (dberkholz) will incorporate these changes into the
proposal and post an update to the -council list.
\agendaitem{Open floor}
\index{PMS}\index{PMS!authoritative repo}
Wulf Krueger (philantrop) asked which PMS repo was authoritative. The
external one had been getting changes, and the "official" gentoo.org one
had not. Mike Doty reported that they're working on allowing non-Gentoo
developers to contribute to the repository, which should resolve the
technical problems. Wulf responded that some people didn't want to
commit to a Gentoo-hosted repository.
|