Re: sustainable development in LilyPond

[Trevor Daniels]

Graham Percival wrote Wednesday, August 04, 2010 9:41 AM
>

> On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote:
> > 1) There is no architectural overview and no program logic manual 
> > to
> > guide new developers through the early stages.
> > This has the advantage that
>
> No; there's no advantage to this.  It's simply due to an imbalance
> of high skill, available time/interest, and an overwhelming number
> of other concerns.
>
> I'm quite aware of the problems that this causes for new
> developers, but as long as we have over 10 patches waiting for
> review for the past few months, the current bottleneck is *not* in
> the initial "getting started" stages.  The current bottleneck is
> reviewing patches.

That's true; but I didn't say this was a current bottleneck,
I said it was a danger to sustainability, the topic we were
discussing.

> The CG section on programming has been improving slowly but
> surely, as have the Frogs.  I wish that we had more Frogs
> submitting doc patches to the CG explaining the stuff they've
> learned instead of leaving that task to the already over-burdened
> Carl, but I didn't think it was worth raising this point directly.

I think it is worth pushing.  Most of LM 3 was written as I
learned how to use the IR.  It doesn't matter if a doc patch
is incorrect - it would almost certainly illicit a rapid
response from a core developer and we would all learn.

> > 2) There is no overall design plan to guide future development.
> > New features are added in an ad hoc fashion at the whim of 
> > individual
> > developers.  The danger is that the overall structure will lose
> > coherence, properties will increasingly behave in inconsistent 
> > ways, and
> > the complexity of the user interface and the barriers to new 
> > developers
> > will increase.
> > At present we rely on Neil and other core developers to
> > maintain the integrity of the design by reviewing patches,
> > but that is not guided development.
>
> This part and parcel with the general way that volunteer
> open-source projects work, though.

I know.  It is probably the greatest defect of OSP.

> Projects with large commercial
> backing (like mozilla and openoffice.org) can give a roadmap with
> the knowledge that they have 20/50/100 developers to assign as
> they wish.

True and of course we can't do this.  But we could set out
some desirable directions and goals.  Consistently thought-out
ones, rather than individual feature requests.  If such a
roadmap existed it might prompt contributors, frogs even, to
work on those items.

> > We have an opportunity within GLISS and GOP to tackle these
> > dangers, although their terms of reference would need to be
> > widened to embrace them.  GLISS would need also to consider
> > future needs and how they would be accommodated in the
> > input syntax, and GOP would have to break down the barriers which 
> > new
> > developers currently have to overcome themselves.
>
> This is possible, but I don't think it's realistic.  In
> particular, it would need:
> 1. a large amount of developer time being placed under the control
> of a benevolent dictator (or council of dictators), and

Yes.  All the most successful OSP have this.

> 2. the "mundane" development tasks to be sustainable, and to have
> enough effort to cover those tasks without needing to distract any
> minions working on #1.
>
> I'd say that we're at least a year away from having sustainable
> mundane tasks... the Bug Squad will probably be sustainable in 2-4
> months, but GDP utterly failed at creating a sustainable doc team,

Don't run this down.  The docs were immeasurably improved by GDP.
This was beneficial dictatorship in action.

It was and still is unrealistic to expect people to work several
hours a day on LP for more than a year or so (with one or two
dedicated exceptions).  So the goal should be to accommodate a
flow of people coming in, working a while, and then leaving.
So we have to make it as easy as possible for newcomers to
contribute easily and quickly, to both docs and development.
The concept of permanent teams is fine, but not teams with
permanent members - there will always be a flow.

> However, IMO we shouldn't be fussing too much about these
> long-term issues until 2.14 is out.  We need a stable foundation.
> (it's a bit unfortunate that the talk was when it was)

OK, agreed.  I've made my comments while they were in my
mind.  I'll back off now.

Trevor