-@subheading Helpers: adding patches
-
-The primary duty is to add patches to the google tracker; we have
-a bad track record of losing patches in email. Patches generally
-come to the @code{lilypond-devel} mailing list, but are sometimes
-sent to @code{bug-lilypond}, @code{lilypond-users}, or
-@code{frogs} mailing list instead.
-
-@itemize
-@item
-Unless a patch is clearly in response to an existing issue, add a
-new issue with the @code{Patch-new} label and a link to the patch
-(either on the mailing list archives or the codereview url).
-
-Issue numbers are cheap; losing developers because they got fed up
-with us losing their hard work is expensive.
-
-@end ignore
-@c if we enter patches immediately, I don't think this is relevant.
-@ignore
-@item
-Before adding a patch-reminder issue, do a quick check to see if
-it was pushed without sending any email. This can be checked for
-searching for relevant terms (from the patch subject or commit
-message) on the webgit page:
-
-@example
-@uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
-@end example
-@end ignore
-@ignore
-
-@item
-If the patch is clearly in response to an existing issue, then
-update that issue with the @code{Patch-new} label and a link to
-the patch (either on the mailing list archives or the codereview
-url).
-
-@item
-After adding the issue, please send a response email to the same
-group(s) that the initial patch was sent to.
-
-If the initial email was sent to multiple mailing lists (such as
-both @code{bugs} and @code{devel}), then reply to all those
-mailing lists as well. The email should contain a link to the
-issue you just added.
-
-@end itemize
-
-@subheading Helpers: @code{Patch-review} label
-
-The secondary duty is to do make sure that every issue in the
-tracker with a @code{Patch-review} label has passed these
-@qq{obvious} tests:
-
-@itemize
-@item
-Applies automatically to git master.
-
-It's ok to have offsets, but not conflicts.
-
-@item
-Regtest comparison looks ok; no unexpected changes.
-
-@item
-Descriptive subject line.
-
-Avoid subjects like @qq{fixes 123}; instead write @qq{Doc: discuss
-stacking-dir for BassFigureAlignment (fix 123)}.
-
-@item
-Compiles docs from scratch. Only check this if you have reason to
-suspect it might not work.
-
-@item
-(maybe)
-
-Check code indentation and style. This should be easier post-GOP
-when we have a better-defined code style.
-
-@end itemize
-
-
-@subheading Patch Meister
-
-The Patch Meister will:
-
-@itemize
-
-@item
-send @qq{countdown} emails to
-@code{lilypond-devel} when patches appear to be ready.
-
-@item
-send general requests to review patches, or even nasty requests to
-review patches.
-
-@item
-downgrade patches from @code{Patch-review} to
-@code{Patch-needs_work} as appropriate.
-
-@item
-downgrade patches from @code{Patch-needs_work} to
-@code{Patch-abandoned} if no actions have been taken in four
-weeks.
-
-@end itemize
-
-@end ignore
-
-
-@node Summary of project status
-@section Summary of project status
-
-@subsubheading Project overview
-
-Grid view provides the best overview: