--- /dev/null
+@c -*- coding: utf-8; mode: texinfo; -*-
+@node Administrative policies
+@chapter Administrative policies
+
+This chapter discusses miscellaneous administrative issues which
+don't fit anywhere else.
+
+@menu
+* Meta-policy for this document::
+* Meisters::
+* Unsorted policies::
+@end menu
+
+@node Meta-policy for this document
+@section Meta-policy for this document
+
+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
+disorganized @qq{wiki-style dump} of information is encouraged.
+
+Do not change (other than spelling mistakes) without discussion:
+
+@itemize
+
+@item
+@ref{Introduction to contributing}
+
+@item
+@ref{Working with source code}
+
+@item
+@ref{Issues}
+
+@end itemize
+
+Please dump info in an appropriate @@section within these manuals,
+but discuss any large-scale reorganization:
+
+@itemize
+
+@item
+@ref{Compiling}
+
+@item
+@ref{Documentation work}
+
+@item
+@ref{Regression tests}
+
+@item
+@ref{Programming work}
+
+
+@end itemize
+
+Totally disorganized; do whatever the mao you want:
+
+@itemize
+
+@item
+@ref{Website work}
+
+@item
+@ref{LSR work}
+
+@item
+@ref{Release work}
+
+@item
+@ref{Administrative policies}
+
+@end itemize
+
+
+
+@node Meisters
+@section Meisters
+
+We have four jobs for organizing a team of contributors:
+
+@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.
+
+Currently: Graham
+
+@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.
+
+Currently: Graham
+
+@item
+Translation Meister: trains new translators, updates the
+translation priority list, and handles merging branches (in both
+directions).
+
+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
+they've had some initial review on the Frog list, pesters the
+@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
+completed patches through our process.
+
+Currently: Carl
+
+@end itemize
+
+
+
+@node Unsorted policies
+@section Unsorted policies
+
+@subsubheading Language-specific mailing lists
+
+A translator can ask for an official lilypond-xy mailing list once
+they've finished all @qq{priority 1} translation items.
+
+@subsubheading Performing yearly copyright update (@qq{grand-replace})
+
+At the start of each year, copyright notices for all source files
+should be refreshed by running the following command from the top of
+the source tree:
+
+@example
+make grand-replace
+@end example
+
+Internally, this invokes the script @file{scripts/build/grand-replace.py},
+which performs a regular expression substitution for old-year -> new-year
+wherever it finds a valid copyright notice.
+
+Note that snapshots of third party files such as @file{texinfo.tex} should
+not be included in the automatic update; @file{grand-replace.py} ignores these
+files if they are listed in the variable @code{copied_files}.
+
+
+@subsubheading Push git access
+
+Git access is given out when a contributor has a significant
+record of patches being accepted without problems. If existing
+developers are tired of pushing patches for a contributor, we'll
+discuss giving them push access. Unsolicited requests from
+contributors for access will almost always be turned down.
+
+
they also stem from attempting to find the most effective use of
limited documentation help.
+Before undertaking any large documentation work, contributors are
+encouraged to contact the @ref{Meisters, Documentation Meister}.
+
@node Documentation suggestions
@section Documentation suggestions
least the documentation so that you can check the output yourself and
more quickly; if you are interested, see @ref{Compiling}.
+Before undertaking any large translation work, contributors are
+encouraged to contact the @ref{Meisters, Translation Meister}.
+
@node Which documentation can be translated
@unnumberedsubsubsec Which documentation can be translated
* Minor release checklist::
* Major release checklist::
* Release extra notes::
-* Administrative policies::
@end menu
@end enumerate
-@node Administrative policies
-@section Administrative policies
-Not really release-specific notes, but I don't see enough material
-here to make it a separate chapter, and the release person will
-probably be the one taking care of this anyway.
-
-@subsubheading Language-specific mailing lists
-
-A translator can ask for an official lilypond-xy mailing list once
-they've finished all @qq{priority 1} translation items.
-
-@subsubheading Performing yearly copyright update (@qq{grand-replace})
-
-At the start of each year, copyright notices for all source files
-should be refreshed by running the following command from the top of
-the source tree:
-
-@example
-make grand-replace
-@end example
-
-Internally, this invokes the script @file{scripts/build/grand-replace.py},
-which performs a regular expression substitution for old-year -> new-year
-wherever it finds a valid copyright notice.
-
-Note that snapshots of third party files such as @file{texinfo.tex} should
-not be included in the automatic update; @file{grand-replace.py} ignores these
-files if they are listed in the variable @code{copied_files}.
projects / lilypond.git / commitdiff