@node Meisters
@section Meisters
-We have four jobs for organizing a team of contributors:
+We have four primary jobs to help organize all our contributors:
+
+@unnumberedsubsec The Bug Meister
+
+The Bug Meister's responsibilities are:
+
+@itemize
+
+@item
+To organize the individual Bug Squad volunteers, making sure that
+each member is aware of their responsibilities. See
+@ref{The Bug Squad}.
+
+@item
+To train new Bug Squad volunteers in the Issue Tracker process. See
+@ref{Issues}.
+
+@item
+To have the final say on our policies for Issues and their
+classification. See @ref{Issue classification}.
+
+@end itemize
+
+Current Bug Meister: Colin Hall @email{bug-lilypond@@gnu.org}
+
+
+@unnumberedsubsec The Doc Meister
+
+The Doc Meister's responsibilities are:
+
+@itemize
+
+@item
+To train new volunteers in our Documentation style and policy,
+including organizing LilyPond Snippet Repository (LSR) work.
+
+@item
+To organize the individual volunteers -- who does what on which job --
+and to check that everything is running smoothly.
+
+@item
+To have final say on any Documentation policy. See
+@ref{Documentation policy}.
+
+@end itemize
+
+Current Doc Meister: None
+
+
+@unnumberedsubsec The Patch Meister
+
+The Patch Meister's responsibilities are:
@itemize
@item
-Bug Meister: trains new Bug Squad volunteers, organizes who works
-on which part of their job, checks to make sure that everything is
-running smoothly, and has final say on our policy for Issues.
+To keep track of all patches submitted for testing and review. This
+includes scanning the bug and dev email lists looking for any patches
+submitted by @q{random} contributors and advising them on how to submit
+a patch for testing and review. See @ref{Uploading a patch for review}
+and @ref{The patch review cycle}.
-Currently: Colin H
+@item
+To makes sure that any patch submitted has a corresponding Issue Tracker
+and Rietveld Issue created for it before it enters the testing and
+review process. See @ref{Issues}.
@item
-Doc Meister: trains new doc editors/writers, organizes who works
-on which part of the job, checks to make sure that everything is
-running smoothly, and has final say on our policy for
-Documentation. Also includes LSR work.
+Updates all Issue statuses for all patches that are currently in the
+testing and review process periodically -- currently every 3 - 4 days.
+See @ref{Patch handling}.
+
+@end itemize
-Currently: None
+@warning{The Patch Meister's role is a purely administrative one and no
+programming skill or judgement is assumed or required.}
+
+Currently: James Lowe @email{pkx@@gnu.org}
+
+
+@unnumberedsubsec The Translation Meister
+
+The Translation Meister's responsibilities are:
+
+@itemize
@item
-Translation Meister: trains new translators, updates the
-translation priority list, and handles merging branches (in both
-directions).
+To train new documentation translators in the translation process. See
+@ref{Translating the documentation}.
-Currently: Francisco
+@item
+To update the translation priority list and handle the merging of the
+translation branches (in both directions).
+
+@item
+To have final say on any Translation management policies. See
+@ref{Translating the documentation}.
@end itemize
+Currently: Francisco Vila @email{translations@@lilynet.net}
+
+
@node Managing Staging and Master branches with Patchy
@section Managing Staging and Master branches with Patchy
@ignore
-The script 'test-patches.py' no longer works with code.google.com since
-Google changed their authentication method.
+The script 'test-patches.py' does not currently work with Allura.
@end ignore
@menu
@item
Commit access @emph{is} required to test and push new commits, but a
-valid login to @uref{http://code.google.com/} is @emph{not}. See
+valid login to @uref{https://sourceforge.net} is @emph{not}. See
@ref{Commit access}.
@end itemize
Reitveld is inconvenient in some respects: it requires a google
account, and there's no way to see all patches relating to
lilypond. Should we switch to something like gerritt?
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1184}
+@uref{https://sourceforge.net/p/testlilyissues/issues/1184/}
(prep: 5 hours. discuss: 15 hours)
(prep: 2 hours. discuss: 10 hours)
@item @strong{code readability}:
-"Our aim when producing source code for Lilypond in whatever
+"Our aim when producing source code for LilyPond in whatever
language is that it should be totally comprehensible to a
relatively inexperienced developer at the second reading."
@item
Discussion on
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
+@uref{https://sourceforge.net/p/testlilyissues/issues/1322/}
about \new vs. \context.
@item
Let users add their own items to the parser? comment 11 on:
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
+@uref{https://sourceforge.net/p/testlilyissues/issues/1322/}
@item
should engravers be pluralized (note_heads_engraver) or not
@item
should we allow numbers in identifier names? Issue:
-@uref{http://code.google.com/p/lilypond/issues/detail?id=1670}
+@uref{https://sourceforge.net/p/testlilyissues/issues/1670/}
@item
should we officially allow accented characters? in general, how
projects / lilypond.git / blobdiff