lilypond-devel
[Top][All Lists]
Advanced

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

Re: ’Pond Jobs & Their Descriptions


From: David Kastrup
Subject: Re: ’Pond Jobs & Their Descriptions
Date: Thu, 06 Feb 2020 01:17:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Kieren MacMillan <address@hidden> writes:

> Hello all!
>
> I’m curious as to all the various jobs/tasks required to keep Lilypond
> development moving forward at the fastest possible pace and in the
> most efficient possible way. Is there a single list compiled anywhere,
> written with an eye to extreme granularity? (The closest I can find is
> <http://lilypond.org/doc/v2.19/Documentation/contributor/help-us>, and
> the 9 bullet points there are at least an order of magnitude fewer
> than the list I’m thinking of.) If not, I’ll start a list,
> brainstormed from my naïve perspective.
>
> Motivation: if we collectively polish it into a clear and complete
> description of the entire Lily-dev ecosystem, we could eventually use
> it to:
>     (a) place existing developers and contributors into their Zone(s) of 
> Genius;
>     (b) identify the most important gaps or under-addressed areas in the 
> pipeline; and
>     (c) help new developers find the best way in to the 'Pond.
>
> Thoughts?

My own current concern, as explained in Salzburg, is to facilitate
completely independent "zones of genius" for the kind of
half-user/half-programmer that embodies "power users" on the user list,
people developing complex solutions and engravers in Scheme.  As
witnessed by their almost daily feats, they have a lot to offer in terms
of individual solutions to small, comparatively individual problems that
would warrant solutions but don't really make a lot of sense integrating
into one core offering of LilyPond.

While there are certainly more comprehensive packages worth making
independently accessible and developable (like edition engraver and much
functionality in openlilylib), the multitude of near-daily offerings
really clamors for some easy archiving and preservation mechanism making
it possible to search for stuff with keywords, have packages downloaded
after browsing their descriptions and try their effects with few lines
of invocation that are trivial to use and revert.

It won't address the issues we are currently discussing with regard to
coordinating changes to the core that have the potential to affect
everyone regardless of whether they need or exercise new added
functionality, but it would enable a large visible and potentially less
visible part of the userbase to exchange and try out solutions in a less
ad-hoc and interactive way than the mailing lists offer.

With regard to the core, my main approach to the "zones of genius"
problem is not as much adding functionality but trying to modularize and
automate interactions between various typesetting elements in a manner
where they become more predictable and the tendency diminishes to have
things falling apart on one end as one adds on the other.

That's all comparatively unsexy and more (re-)organisation and janitoral
than actual creative work.

And if you take a look at the rooms I am living in, you would not judge
me the best suited person for tidying up things, either.

Nevertheless, I feel I am pretty solitary with that kind of aim which I
consider sort of important for bringing a critical mass of contributors
in before they start repelling one another :)

-- 
David Kastrup



reply via email to

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