Merge branch 'master' into lilypond/translation

[lilypond.git] / Documentation / contributor / administration.itexi

diff --git a/Documentation/contributor/administration.itexi b/Documentation/contributor/administration.itexi
index aef67b3beaa6b2dbe202f6d2e0d529d8500298c0..36ead431e159695f3989bc9ec7861ce3fe57eb8c 100644 (file)
--- a/Documentation/contributor/administration.itexi
+++ b/Documentation/contributor/administration.itexi
@@ -20,7 +20,7 @@ don't fit anywhere else.
 The Contributor's Guide as a whole is still a work in progress,
 but some chapters are much more complete than others.  Chapters
 which are @qq{almost finished} should not have major changes
-without a discussion on @code{-devel}; in other chapters, a
+without a discussion on @w{@code{-devel}}; in other chapters, a
 disorganized @qq{wiki-style dump} of information is encouraged.
 
 Do not change (other than spelling mistakes) without discussion:
@@ -110,9 +110,9 @@ Currently: Francisco
 @item
 Frog Meister: is responsible for code patches from (relatively)
 inexperienced contributors.  Keeps track of patches, does initial
-reviewing of those patches, sends them to @code{-devel} when
+reviewing of those patches, sends them to @w{@code{-devel}} when
 they've had some initial review on the Frog list, pesters the
-@code{-devel} community into actually reviewing said patches, and
+@w{@code{-devel}} community into actually reviewing said patches, and
 finally pushes the patches once they're accepted.  This person is
 @emph{not} responsible for training new programmers, because that
 would be far too much work -- he job is @qq{only} to guide
@@ -163,6 +163,7 @@ difficult tasks.
 * Motivation::
 * Ongoing jobs::
 * Policy decisions::
+* Policy decisions (finished)::
 @end menu
 
 @node Motivation
@@ -504,8 +505,67 @@ amount of current material in either form, are important.
 
 (prep: 5 hours.  discuss: 15 hours)
 
+@item @strong{always make an issue number for patches}:
+there is a proposal that we should always have a google code issue
+number for every patch.  This proposal is closely tied to our
+choice of patch review tool; if we switch to a different tool (as
+suggested in a different proposal), this proposal may become moot.
+
+(prep: 1 hour.  discuss: 5 hours)
+
+@item @strong{initalizer lists}:
+shoudl we use initalizer lists for C++?  AFAIK they make no
+difference for built-in types, but there's some weird case where
+it's more efficient for objects, or something.
+
+Probably not worth making this a weekly thing on its own, but we
+can probably wrap it up with some other code-related questions.
+
+(prep: 15 minutes.  discuss: 3 hours)
+
+@end itemize
+
+@node Policy decisions (finished)
+@subsection Policy decisions (finished)
+
+@subheading GOP-PROP 1: python formatting
+
+We will follow the indentation described in PEP-8.
+@uref{http://www.python.org/dev/peps/pep-0008/}
+
+@itemize
+@item
+use 4 spaces per indentation level
+
+@item
+never mix tabs and spaces (for indentation)
+
+@item
+Code indented with a mixture of tabs and spaces should be
+converted to using spaces exclusively
+
+Once this is done, we should add @code{python -tt} to the build
+system to avoid such errors in the future.
+
 @end itemize
 
+There should be absolutely no tab characters for indentation in
+any @code{.py} file in lilypond git.  All such files should be
+converted to use spaces only.
+
+
+@subheading GOP-PROP 2: mentors and frogs
+
+Nothing much was decided.  The list of responsibilities was
+slightly altered; see the new one in @ref{Mentors}.  We should
+encourage more use of the Frogs mailing list.  There's a list of
+contributor-mentor pairs in:
+
+@smallexample
+@uref{https://github.com/gperciva/lilypond-extra/blob/master/people/mentors.txt}
+@end smallexample
+
+That's pretty much it.
 
 
 @node Grand LilyPond Input Syntax Standardization (GLISS)
@@ -741,7 +801,9 @@ Capitalization of identifiers: \VoiceOne ?
 @end verbatim
 
 ?  patch here:
+@smallexample
 @uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00467.html}
+@end smallexample
 
 @item
 Personally, I find it easier to understand when there's a repeated
@@ -799,13 +861,13 @@ sequential-statement to the score."
 
 @item
 Discussion on
-http://code.google.com/p/lilypond/issues/detail?id=1322
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
 about \new vs. \context.
 
 
 @item
 Let users add their own items to the parser?  comment 11 on:
-http://code.google.com/p/lilypond/issues/detail?id=1322
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
 
 @item
 should engravers be pluralized (note_heads_engraver) or not
@@ -813,7 +875,7 @@ should engravers be pluralized (note_heads_engraver) or not
 
 @item
 should we allow numbers in identifier names?  Issue:
-http://code.google.com/p/lilypond/issues/detail?id=1670
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1670}
 
 @item
 should we officially allow accented characters?  in general, how
@@ -833,6 +895,11 @@ and never allowing
   \transpose c d e1
 @end verbatim
 
+@item
+What should be the officially encouraged way of writing music for
+transposing instruments? Maybe it should be simplified?
+See http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00130.html
+
 @end itemize