summaryrefslogtreecommitdiff
blob: 9853688f1a2ce6da795efaf51e025215332af55c (plain)
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.