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:
@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
(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)
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)
@section Grand LilyPond Input Syntax Standardization (GLISS)
@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
@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
@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
\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