Re: Membership request for group GNU LilyPond Music Typesetter

[Graham Percival]

On Mon, 26 May 2008 23:37:36 -0300
"Han-Wen Nienhuys" <address@hidden> wrote:

> Push access means:
> 
> -a contributor has to prove himself reliable
> 
> -savannah hoop jumping
> 
> -some handholding to make sure that no disasters are pushed to our
> repo
> 
> theoretically, with forks, we don't have to deal with this, and can
> cherry-pick patches on a one-by-e case.

Hmm.  I guess I don't quite understand what you mean by a fork vs.
a branch.  Here's what I want:

- two people capable of updating snippets.  This means write
  access to input/new/ and input/lsr/, and one-line write access
to Documentation/user/  (to update the snippet names if any are
renamed).

- *if* we have somebody maintaining the predefined commands,
  that person needs write access to ly/ .

- skilled doc writers understand the doc policy and knows what
  they're doing.  So far this is one person (Trevor).

The first two items need to be included (sync'd up?) in each
-devel release, because future doc work depends on them.  I
suppose that the docs don't /really/ need to be sync'd for each
release, but it would be nice.

Since I don't really understand what you mean by "forks", I don't
know how this would improve things... unless you're suggesting
that we split the documentation away from the source code, and put
it in an entirely separate doc tree.  I wouldn't be opposed to
this (ie Documentation/ and input/ get moved; input/regression
stays in the source tree), but I'm not certain that it's worth all
the work to separate the trees.


> Also, you mention that you spend a lot of time on people that do not
> have push access.  The interesting question is: where is that time
> going?  If we can make all those contributors spend a few minutes more
> each day on preparing and verifying their changes, a lot of time can
> be saved.

If we required that people build the docs themselves, it would
save me some time... but it would also eliminate at least half the
contributors.

> It may be moot for you in the sense that you are leaving, but it would
> be good to fix the problems in the process, so the next person does
> not also get bogged down the same way you are.

Yes and no; once I'm gone, it doesn't make sense to hand-hold new
contributors.  The remaining doc writers can fix issues much
faster than it would take to help new people learn the ropes.


The biggest thing (for me) is that once I identify a well-defined,
small job (such as updating snippets, or being in charge of
ly/property-init.ly), and once I've trained somebody to do that, I
want to delegate it.  I don't want to ever touch or think about
that stuff again.  This requires people getting git access to deal
with small jobs.

Cheers,
- Graham