blob: d40a8cbb7485beb4e7735bc44bc2df85158ed308 (
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
|
\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} (for the
attachment see \ref{2007-11-dberkholz-coc})
\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.
|
GitWeb