Leaving: replacements

[Graham Percival]

An previously announced, am I gradually leaving LilyPond.  This
leaves a large number of tasks unfilled.

Please seriously consider helping lilypond.  If one person
attempts to do everything in this list, they will quickly get
burned out.  Some of these tasks might seem trivial, but spreading
the load would help a *lot*.  In addition, freeing up these
trivial tasks lets the more technically advanced volunteers work
on... well, more technically advanced problems.  :)

Some jobs naturally go with other jobs in this list, but they can
all be done independently.  My greatest wish is we get enough
volunteers such that these jobs _will_ be done independently: that
will severely limit the amount of burn-out.


Times are given in hours per week, and the estimates are generally
slightly exaggerated -- in other words, if it says "2 hours per
week", it should normally take you less than that.


EASY  (no technical/unix skills, low lilypond knowledge required)

- lilypond-user secretary (0.5 hours**): we need to somebody to
  read the user mailist and direct inquiries to the appropriate
  place.  In other words, whenever somebody says "this should be
  in the docs", you send them a link to
http://lilypond.org/web/devel/participating/documentation-adding
  Whenever somebody says "is this a bug", you send them
http://lilypond.org/web/devel/participating/bugs
  Whenever there's a nice example, tell them to submit it to LSR.

  The ** indicates that it's 30 minutes if you normally read
  lilypond-user.  I don't (well, I don't want to), so this
  suddenly balloons to over 5 hours a week.  This is easily the
  second-worst job I had, but _definitely_ the easiest for
  somebody else to do.

%  currently done by Valentin
- LSR adder (0.5 hours): when there's a nice example on
  lilypond-user, add it to LSR.

% three volunteers so far: 
%    Garrett Fitzgerald
%    Stan Sanderson
%    Alexander Deubelbeiss
% it's great that we have so many interest in this, but it
% might be good if one or two of you took other jobs
- Regression test checker (0.5 hours): I never actually did this
  job, but I should have been.  Whenever a new version of lilypond
  is released, look at the regression tests to see if anything
  broke.  There's even an automatic system that highlights
  differences between versions.


MEDIUM  (no technical/unix skills, moderate lilypond knowledge)

- lilypond-bug secretary (3 hours): if a bug report is minimal,
  add it to the google tracker.  If it isn't minimal, either
  create a minimal example, or ask the submitter to do a better
  job.  If you reject any non-minimal submissions, it's 1 hour per
  week.  If you're a nice guy and create minimal examples
  yourself, it's 5 hours.  I try to be somewhere in the middle.

- Bug Meister (0.5 hours): when a bug is marked fixed and that
  release is available, test the fixed bugs and mark them
  verified.  Occasionally goes throught the list of bugs, checking
  if they still exist, if any comments were lost, etc.
  Ideally the same person as the lilypond-bug secretary, but it
  could be somebody else instead.

% Valentin
- LSR editor (1 hour): review new submissions (or corrections for
  existing submissions) for LSR and approve them.  (the time is
  for the ongoing maintenance of LSR, not the initial setup.  :)


HARD  (knowledge of git, how to build the docs)

% John
- LSR->GIT (0.25 hours): download the LSR tarball, run the
  buildscripts/makelsr.py script, then carefully review the
  changes to make sure that there's no nasty unsafe scheme.  (once
  per month is fine)

- Documentation Writer (1 hour): write new documentation for new
  features (or old features that were never documented).
  (time for ongoing maintenance, not for GDP)

- Documentation Editor (1 hour): when there's a submission to
  lilypond-devel (*not* lilypond-user) for new docs, add them.  If
  there's a bug discussion that requires noting the bug in the
  docs, do it.  Review the new docs written by others (for
  spelling, grammar, general English, how they fit into the docs
  as a whole, etc).  Occasionally rewrite old docs if they can be
  significantly improved.
  (time for ongoing maintenance, not for GDP)


Cheers,
- Graham