Index 2007/12 to 2008/5

1 files changed, 98 insertions, 0 deletions

diff --git a/decisions/summary-20071213.tex b/decisions/summary-20071213.tex
new file mode 100644
index 0000000..ee0c2c9
--- /dev/null
+++ b/decisions/summary-20071213.tex
@@ -0,0 +1,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-dec}\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.