summaryrefslogtreecommitdiff
blob: 6472b329d8c11ac4401b6b6b9189337b27aba6e6 (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
\summary{2007}{12}{13}

Agenda call: \agoref{gentoo-dev}{ba2cdfa0060c1a2b7583e19185564855}


\agendaitem{New USE documentation}
\index{USE}\index{global changes}\index{metadata.xml}

Reference: http://archives.gentoo.org/gentoo-dev/msg_149120.xml (dead 
link)\footnote{This is likely the 
\agoref{gentoo-dev}{dcc6227eceaa2a4999e6a2a256dcddbc}.}

Considering the precedent set by how the documentation of use flags in 
metadata.xml was implemented, what should we do? Should we leave it in place or 
revert it? Should we require a GLEP?

The result of the discussion was:
\begin{enumerate}
\item 
We're leaving this improvement in place, and are considering further changes.
\item
It should have been posted to the gentoo-dev mailing list before committing 
for discussion.
\end{enumerate}

The general process for global changes shall be:\footnote{This algorithm isn't 
really spelled out that clearly in the log. It's kinda common sense though.}
\begin{itemize}
\item 1. Post to gentoo-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 a GLEP. Discuss it on gentoo-dev. Submit the GLEP to the 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. The 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 are 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}\index{project!userrel}\index{project!devrel}

References: 
\begin{itemize}
 \item 
 \agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979}
 \item
 November 2007 council meeting summary
\end{itemize}

\dev{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}

\dev{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?

\dev{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 Kr├╝ger (philantrop) asked which PMS repo was authoritative. The 
external one had been getting changes, and the "official" gentoo.org one 
had not. \dev{kingtaco} 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. Some discussion ensued.