lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Membership request for group GNU LilyPond Music Typesetter


From: Han-Wen Nienhuys
Subject: Re: Membership request for group GNU LilyPond Music Typesetter
Date: Mon, 26 May 2008 23:37:36 -0300

2008/5/26 Graham Percival <address@hidden>:
> Having more people doing smaller tasks is completely deliberate.
> If you're only responsible for 30 minutes of work each week, you
> won't get burned out, and you really can't pretend that you're too
> busy to find those 30 minutes somewhere.
>
> OTOH, if you do two hours of work each day, you get burned out
> really quickly.
>

This isn't really about how much time someone spends, but rather  how
we should scale access to the repository.  If we have lots of people
pushing to the master branch, a bad push by a single person will
affect all contributors.  Of course, we can have the contributors
pushing to side-branches (gdp, translations, what have you), but then
the effect is really the same as pulling from different repositories,
at which point the idea of forks becomes relevant, as starting a fork
presumably has a lower threshold than getting push access.

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.

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.

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.

> I'm gone in three months.  This leaves three options:
> 1. lose all the extra contributors.
> 2. have the extra contributors send material to somebody else (you?
>  John?), and that other person starts spending an hour a day
> dealing with this stuff.  Or maybe only deal with them once a
> week, potentially dealing with them in 3 hours a week... but then
> you might lose half the contributors.  People don't like waiting a
> week for feedback; I think that one of the reasons GDP has
> worked out is that 95% I respond within 24 hours.
> 3. start giving trusted, reliable contributors git access.
>
> I favor #3, of course.

As people are leaving the project, we have to give their (potential)
successors access.  That goes without saying. My point is that we
could look at ways of dealing with the #2 people more efficiently.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]