Re: ’Pond Jobs & Their Descriptions

[Janek Warchoł]

Kieren,

I see that I've misunderstood you - I apologize. My LP time today is over,
so I'll follow on this topic on the next occasion :)

sob., 8 lut 2020 o 23:31 Kieren MacMillan 
napisał(a):

> Hi Janek,
>
> > I appreciate the initiative, and I agree that we could use a clearer
> view on the responsibilities and skills needed in the community. However, I
> am pretty sure that creating a detailed list is not an effective way of
> solving this problem. I'm pretty sure that we'd spend a *lot* of time on
> discussion and even if we agree on the results, it'll be even more work to
> implement the processes
>
> What processes? I never suggested any processes be developed or
> implemented.
>
> > and until it's ready there would be no tangible benefits
>
> I don’t see that as a necessary condition of what I’m suggesting.
>
> > Do you know about agile methodologies?
>
> Yes. And in fact I’m trying to use them.  :)
>
> > start with setting a small self-contained goal, complete it (with only
> basic planning), and when you're done you take step back to include what
> you've learned in the process.
>
> That’s exactly what I’m doing.
>
> > I suggest to ask this question: what are the 3 areas where LP community
> is most "shortstaffed"?
>
> I’m curious how you’re going to answer that question without actually
> knowing what the areas of the LP community are.
>
> > Once we discover that, I would go on asking "what's the one thing that
> would make it easier/more attractive to contribute in that area". Boom, 2
> weeks later we actually have some specific improvements.
>
> Well, nothing is stopping you from doing that in parallel to my [personal]
> effort.
>
> > I'm willing to mentor, as I've committed to improving LP contributor
> experience
>
> Just an FYI: I’m not going to even bother trying to set up any
> repositories or LilyDev or anything development-related until the
> contributor experience and toolchain is settled on. So the sooner you get
> that done, the sooner you can mentor me in whatever the new processes and
> toolchains are.
>
> Regards,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Janek,

> I appreciate the initiative, and I agree that we could use a clearer view on 
> the responsibilities and skills needed in the community. However, I am pretty 
> sure that creating a detailed list is not an effective way of solving this 
> problem. I'm pretty sure that we'd spend a *lot* of time on discussion and 
> even if we agree on the results, it'll be even more work to implement the 
> processes

What processes? I never suggested any processes be developed or implemented.

> and until it's ready there would be no tangible benefits

I don’t see that as a necessary condition of what I’m suggesting.

> Do you know about agile methodologies?

Yes. And in fact I’m trying to use them.  :)

> start with setting a small self-contained goal, complete it (with only basic 
> planning), and when you're done you take step back to include what you've 
> learned in the process.

That’s exactly what I’m doing.

> I suggest to ask this question: what are the 3 areas where LP community is 
> most "shortstaffed"?

I’m curious how you’re going to answer that question without actually knowing 
what the areas of the LP community are.

> Once we discover that, I would go on asking "what's the one thing that would 
> make it easier/more attractive to contribute in that area". Boom, 2 weeks 
> later we actually have some specific improvements.

Well, nothing is stopping you from doing that in parallel to my [personal] 
effort.

> I'm willing to mentor, as I've committed to improving LP contributor 
> experience

Just an FYI: I’m not going to even bother trying to set up any repositories or 
LilyDev or anything development-related until the contributor experience and 
toolchain is settled on. So the sooner you get that done, the sooner you can 
mentor me in whatever the new processes and toolchains are.

Regards,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Janek Warchoł]

Hi Kieren,

czw., 6 lut 2020 o 00:55 Kieren MacMillan 
napisał(a):

> 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.
>

I appreciate the initiative, and I agree that we could use a clearer view
on the responsibilities and skills needed in the community. However, I am
pretty sure that creating a detailed list is not an effective way of
solving this problem. I'm pretty sure that we'd spend a *lot* of time on
discussion and even if we agree on the results, it'll be even more work to
implement the processes, and until it's ready there would be no tangible
benefits. My whole professional experience taught me that such
planning-heavy approaches are costly and often fail.

Do you know about agile methodologies? In short, they are about doing work
iteratively: instead of making a detailed plan and following it (usually
until you discover midway that, because of missing data, half of the plan
doesn't make sense), start with setting a small self-contained goal,
complete it (with only basic planning), and when you're done you take step
back to include what you've learned in the process. It usually yields much
better results. You may find this link helpful (but I suggest that you
don't go on reading everything on that site):
https://www.atlassian.com/agile/manifesto

Therefore I suggest to apply the Pareto principle (
https://en.wikipedia.org/wiki/Pareto_principle) and do something much more
lightweight. For example, I suggest to ask this question: what are the 3
areas where LP community is most "shortstaffed"? (e.g. do we need more
people to do patch review, testing automation, whatever?). Once we discover
that, I would go on asking "what's the one thing that would make it
easier/more attractive to contribute in that area". Boom, 2 weeks later we
actually have some specific improvements.


czw., 6 lut 2020 o 01:21 Graham Percival 
napisał(a):

> On Wed, Feb 05, 2020 at 06:55:38PM -0500, Kieren MacMillan wrote:
>
> (c) help new developers find the best way in to the 'Pond.
>
> I'm not up to date on current LilyPond,


Whoah, Graham! Nice to see you, man! Long time no see :-)


> but I suspect that the
> answer is "try to find developers willing to mentor".


I'm willing to mentor, as I've committed to improving LP contributor
experience (even though not much happened on that front from my side, as I
got sidetracked by huge CoC discussion).

BTW do you remember that about 8 years ago I promised you to mentor some
"Frogs" when my patch for shortened flags will be merged? It's still not
done, but whatever, I want to keep my promise ;-)

Best,
Janek

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Wol,

> Rather than jobs as in people, why not jobs as in tasks?

That’s really what I’m doing (though I may have failed to make that clearer): a 
person can certainly take on more than one job/task.

> Take your list of jobs like "Patch Formatter", and change it into a list
> of stages a patch must path through like "format the patch correctly".

If that makes it clearer for people, I’m happy to format the list that way.

> If you have a list of people who are happy with certain tasks - and yes
> they are really mentors - then people who want to get started can tackle
> a simple project and ask for help getting it through the relevant stages.

Facilitating exactly that is one of the three main goals of my effort.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Wols Lists]

On 06/02/20 13:24, Kieren MacMillan wrote:
> Why not let someone less experienced — and thus less "valuable" — start with 
> that job as a "softball" to ease their way into the development pool, freeing 
> up higher-level developers to (as you say) spend your time where it matters? 
> To me, doing that sounds like a win-win situation.
> 
> In any case, I’m going to build the list for my own benefit; if, when I’m 
> done, it helps the greater community, all the better.

Rather than jobs as in people, why not jobs as in tasks?

Take your list of jobs like "Patch Formatter", and change it into a list
of stages a patch must path through like "format the patch correctly".

Then people can offer to shepherd patches through certain stages, or
they can say "I'm good at this, I need help with that, can someone else
do the other". I know I had a patch fail because I wasn't in a position
to really make a bunch of changes the reviewer wanted - I don't like
"begging" for help and I was really rather out of my depth already
without being asked to do more stuff ...

If you have a list of people who are happy with certain tasks - and yes
they are really mentors - then people who want to get started can tackle
a simple project and ask for help getting it through the relevant stages.

And you really need a bunch of people who are prepared to mentor and
respond reasonably quickly to pretty stupid questions. Although I'm
quite happy for the guidelines to state that mentees must be prepared to
learn as quickly as possible and that mentors *should* walk away if they
feel the mentee isn't really trying to do as much as they can on their own.

Cheers,
Wol

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi David,

> The way I read the request I thought is was more about having an
> organizational document, not for the sake of getting a submission in,
> but rather for understanding where help in improving the processes (by
> code or manual labor) would be appreciated, and what kind of expertise
> this would entail.

It might have been those drinks at the Johanneskeller, but I think you and I 
might finally be thinking the same way…  ;)

> Well, we don't really point out helpful resources for that a lot, do we?

+1
I’m hoping my document will do that, if only for me.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Jonas,

> certainly not a "Patch Formatter", that's part of the review process
> which is no job, every developer should participate.

The largest [commercial] programming project I was ever on had about 40 
developers working on it. When I first joined, they put me on code formatting 
[only] for two days, so I could get used to their workflow and toolchain (CVS, 
etc.). Once I was comfortable with that, and them with me, they moved me to 
error throw/catch work for a week. Only after that period of time did we both 
feel like I could move on to full contribution to the codebase.

Obviously there are [big] differences between open-source projects and 
commercial projects/jobs… but I personally think that my own way past the 
significant "wall" of beginning Lilypond development is to start with something 
as small as possible, and I’m betting there are others out there that feel the 
same.

Best regards,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[David Kastrup]

Jonas Hahnfeld  writes:

> Am Mittwoch, den 05.02.2020, 21:24 -0500 schrieb Kieren MacMillan:
>> Hi again, Graham:
>> 
>> More concretely… Where can I go, in the CG or elsewhere, to find
>> something that looks like this:
>> 
>> Job: Patch Formatter
>> Tasks: Ensure that a submitted patch conforms to the Lilypond code
>> standards (found  and  and ).
>> Requirements: a text editor; working knowledge of the programming
>> language(s) used in a given patch (possibilities: C++, Scheme,
>> python).
>> Estimated Time Commitment: 5 minutes (per average patch), currently
>> an average of 7 patches per week
>> References & Links: , > auto-formatting tools here>, etc.
>> Receives From: Patch Submitter or Patch Reviewer
>> Passes To: Patch Reviewer
>
> My thoughts: Formalizing to that degree hurts an open source project
> instead of helping. It gives new contributors a lot more to understand
> to even start and decreases efficiency for developers, as every micro-
> managing does in day jobs. Personally I don't want to see tens of jobs
> that I all have to memorize in order to contribute.

The way I read the request I thought is was more about having an
organizational document, not for the sake of getting a submission in,
but rather for understanding where help in improving the processes (by
code or manual labor) would be appreciated, and what kind of expertise
this would entail.

I may have been completely misunderstanding Kieren here, but that might
be of interest anyway.

> I'm open to reconsider the current description of jobs, adapt if
> necessary, and add new jobs if really needed - but certainly not a
> "Patch Formatter", that's part of the review process which is no job,
> every developer should participate.

Well, we don't really point out helpful resources for that a lot, do we?

> Jonas


-- 
David Kastrup

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Han-Wen,

> I think this is going at it from the wrong direction.

I think you may not be the only one.  =)

> The above tasks are what automation is for. For example, with clang-format, 
> you can have a process that would automatically check if a patch is correctly 
> formatted.  The whole discussion around process/tooling is to make these jobs 
> disappear.

I agree 100%.

> Graham is exactly right: we need more automation, so we can spend our time 
> where it matters.

I also agree 100%.

That doesn’t change the fact that I would personally like to see the list of 
jobs broken down, to figure out where I can best put my [limited] time and 
[limited] skills right now, and possibly help other beginning developers figure 
out their own way(s) into Lilypond development.

A huge barrier for me getting into Lilypond development has been the monolithic 
nature (or at least appearance) of the process: it sure seems like, in order to 
add one tiny piece of syntactic sugar to the codebase, I need to be able to
(a) set up my own virtual machine;
(b) have multiple Git*/etc. accounts on multiple different platforms;
(c) write the code;
(d) document it;
(e) format it;
(f) test it;
(g) shepherd it;
  

I don’t know about anyone else, but that’s overwhelming for me.

A smoother way into the development process for me would be to (e.g.) go 
through 100 patches, format them correctly, and [re]submit. It sounds like 
grunt work to you — and it is! — but it would allow me to get my own toolchain 
in place, have a mentor guide me and show me best practices, increase my 
confidence in navigating the process, increase my exposure to the codebase,  
  Once I had some momentum, then I could try to tackle two or three or all 
of the steps myself as a single process.

> with regard to the patch process, there is only one step that can't be 
> automated away

Great. Are all those automations in place? Auto-documentation is a thing?

> that is visual inspection of the regtest results, but this only applies if 
> there are any, and if they were generated automatically, the reviewer and 
> submitter could do it for themselves.

Why not let someone less experienced — and thus less "valuable" — start with 
that job as a "softball" to ease their way into the development pool, freeing 
up higher-level developers to (as you say) spend your time where it matters? To 
me, doing that sounds like a win-win situation.

In any case, I’m going to build the list for my own benefit; if, when I’m done, 
it helps the greater community, all the better.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Urs,

> If I'm not mistaken such a list wouldn't/shouldn't imply that
> separating jobs relies on assigning one job per person

Correct. Someone *could* do just one of those things, but likely wouldn’t.

> It *might* be misleading someone to think your effort would go in that
> direction of a strictly formalized working environment, but a) we don't
> have so many people for so many jobs and b) of course many people can
> do much more than one task of such a list.

Exactly.

> But such a detailed "job description" would probably be very helpful
> when thinking about a possible improvement/solution/patch: What do I
> want, what is needed to achieve it, which parts can I do myself, for
> what exactly do I need assistance?

Precisely!

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Han-Wen Nienhuys]

On Thu, Feb 6, 2020 at 2:40 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> > I suspect that you want a "less extremely granular" list
>
> No. I want what I asked for: a hyper-granular list like
>
>Patch-Related Jobs:
>Patch Coding
>Patch Mentoring
>Patch Optimization
>Patch Documentation
>Patch Formatting
>Patch Submission
>Patch Shepherding
>Patch Testing
>Patch Review
>Patch Approval
>Patch Pushing
>Patch Confirmation
>
> etc., in which, for example, Patch Testing and Patch Review are two
> different jobs. Also note that "Patch-Related Jobs" might represent only
> 1/5th of the total number of jobs in the ’Pond.
>

I think this is going at it from the wrong direction. The above tasks are
what automation is for. For example, with clang-format, you can have a
process that would automatically check if a patch is correctly formatted.
The whole discussion around process/tooling is to make these jobs disappear.

Graham is exactly right: we need more automation, so we can spend our time
where it matters. The thing that is hard, is gaining understanding of how
the code base works, and then applying that to teach others or to review
potential submissions.

>  1) summarize the jobs that are described in the CG
> >  2) check if those descriptions are still accurate
>
> I’m happy to start there. I just wanted to make sure my *invention* of the
> wheel wasn’t *re-*.  :)
>
> > I suspect that "automation tools" would be the most impactful
> improvements.
>
> Of what job(s)? If we don’t know all the steps, how they combine, how many
> people can/do execute them, and what the precise toolchain options are (or
> could be), talk of automating them seems premature to me.
>

with regard to the patch process, there is only one step that can't be
automated away, and that is visual inspection of the regtest results, but
this only applies if there are any, and if they were generated
automatically, the reviewer and submitter could do it for themselves.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: ’Pond Jobs & Their Descriptions

[Jonas Hahnfeld]

Am Mittwoch, den 05.02.2020, 21:24 -0500 schrieb Kieren MacMillan:
> Hi again, Graham:
> 
> More concretely… Where can I go, in the CG or elsewhere, to find something 
> that looks like this:
> 
> Job: Patch Formatter
> Tasks: Ensure that a submitted patch conforms to the Lilypond code standards 
> (found  and  and ).
> Requirements: a text editor; working knowledge of the programming language(s) 
> used in a given patch (possibilities: C++, Scheme, python).
> Estimated Time Commitment: 5 minutes (per average patch), currently an 
> average of 7 patches per week
> References & Links: ,  tools here>, etc.
> Receives From: Patch Submitter or Patch Reviewer
> Passes To: Patch Reviewer

My thoughts: Formalizing to that degree hurts an open source project
instead of helping. It gives new contributors a lot more to understand
to even start and decreases efficiency for developers, as every micro-
managing does in day jobs. Personally I don't want to see tens of jobs
that I all have to memorize in order to contribute.

I'm open to reconsider the current description of jobs, adapt if
necessary, and add new jobs if really needed - but certainly not a
"Patch Formatter", that's part of the review process which is no job,
every developer should participate.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: ’Pond Jobs & Their Descriptions

[Urs Liska]

Am Mittwoch, den 05.02.2020, 22:26 -0500 schrieb Kieren MacMillan:
> Hi Graham,
> 
> > Oh, that would definitely be a good idea!
> 
> Okay, then! I’ll start with your suggestion to [paraphrasing:]
> "summarize the jobs described in the CG", and prepare a skeleton
> document where each entry is like that one.
> 
> > (I'm not quite certain about the "Receives From" and "Passes To"
> > lines, as I think that implies a more formalized process than
> > LilyPond has
> 
> Those would be more for understanding the flow of the process, and
> figuring out where combinations/elisions can happen (e.g., someone
> might have sufficient skill and interest to be both Patch Submitter
> and Patch Formatter), and where automation can help (e.g., code
> formatting LOL).

If I'm not mistaken such a list wouldn't/shouldn't imply that
separating jobs relies on assigning one job per person (wow, why do my
fingers insist typing "mob" instead of "job" this morning???)

It *might* be misleading someone to think your effort would go in that
direction of a strictly formalized working environment, but a) we don't
have so many people for so many jobs and b) of course many people can
do much more than one task of such a list.
But such a detailed "job description" would probably be very helpful
when thinking about a possible improvement/solution/patch: What do I
want, what is needed to achieve it, which parts can I do myself, for
what exactly do I need assistance?

Urs

> 
> Best,
> Kieren.
> 
> 
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
> 
> 

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Graham,

> Oh, that would definitely be a good idea!

Okay, then! I’ll start with your suggestion to [paraphrasing:] "summarize the 
jobs described in the CG", and prepare a skeleton document where each entry is 
like that one.

> (I'm not quite certain about the "Receives From" and "Passes To"
> lines, as I think that implies a more formalized process than LilyPond has

Those would be more for understanding the flow of the process, and figuring out 
where combinations/elisions can happen (e.g., someone might have sufficient 
skill and interest to be both Patch Submitter and Patch Formatter), and where 
automation can help (e.g., code formatting LOL).

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Graham Percival]

On Wed, Feb 05, 2020 at 09:24:37PM -0500, Kieren MacMillan wrote:
> Job: Patch Formatter
> Tasks: Ensure that a submitted patch conforms to the Lilypond code standards 
> (found  and  and ).
> Requirements: a text editor; working knowledge of the programming language(s) 
> used in a given patch (possibilities: C++, Scheme, python).
> Estimated Time Commitment: 5 minutes (per average patch), currently an 
> average of 7 patches per week
> References & Links: ,  tools here>, etc.
> Receives From: Patch Submitter or Patch Reviewer
> Passes To: Patch Reviewer

Oh, that would definitely be a good idea!

(I'm not quite certain about the "Receives From" and "Passes To"
lines, as I think that implies a more formalized process than
LilyPond has, but the rest would be *fantastic*!)

Cheers,
- Graham

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi again, Graham:

More concretely… Where can I go, in the CG or elsewhere, to find something that 
looks like this:

Job: Patch Formatter
Tasks: Ensure that a submitted patch conforms to the Lilypond code standards 
(found  and  and ).
Requirements: a text editor; working knowledge of the programming language(s) 
used in a given patch (possibilities: C++, Scheme, python).
Estimated Time Commitment: 5 minutes (per average patch), currently an average 
of 7 patches per week
References & Links: , , etc.
Receives From: Patch Submitter or Patch Reviewer
Passes To: Patch Reviewer

?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Carl,

> More sources:
> http://lilypond.org/doc/v2.19/Documentation/contributor/meisters
> http://lilypond.org/doc/v2.19/Documentation/contributor/the-bug-squad

Thanks! Very helpful links.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi David,

> My own current concern, as explained in Salzburg

I enjoyed your talk very much.

> 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.

Yes. I’m 100% on board with that. But I personally need to see a complete list 
of granularized tasks/jobs before I can even figure out where *I* best fit in, 
never mind where someone I just met on-list might fit in.

> 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

I disagree: my whole point is to get a full, highly-detailed "map" of the 
entire ecosystem, core and non-core, so that the discussion can move forward in 
a more rational way.

> 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 a *technical* goal. I’m working on an *organizational* goal [which, 
hopefully, fully supports your technical goal and eases the path to success].

Best,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Kieren MacMillan]

Hi Graham,

> If you want "extreme granularity", then wouldn't that be the whole 
> Contributor's Guide?

Well, (a) for starters 'no'… ;) and (b) even if 'yes', it sure wouldn’t be best 
presented in that format.  ;)

> I suspect that you want a "less extremely granular" list

No. I want what I asked for: a hyper-granular list like

   Patch-Related Jobs:
   Patch Coding
   Patch Mentoring
   Patch Optimization
   Patch Documentation
   Patch Formatting
   Patch Submission
   Patch Shepherding
   Patch Testing
   Patch Review
   Patch Approval
   Patch Pushing
   Patch Confirmation

etc., in which, for example, Patch Testing and Patch Review are two different 
jobs. Also note that "Patch-Related Jobs" might represent only 1/5th of the 
total number of jobs in the ’Pond.

>  1) summarize the jobs that are described in the CG
>  2) check if those descriptions are still accurate

I’m happy to start there. I just wanted to make sure my *invention* of the 
wheel wasn’t *re-*.  :)

> I suspect that "automation tools" would be the most impactful improvements.

Of what job(s)? If we don’t know all the steps, how they combine, how many 
people can/do execute them, and what the precise toolchain options are (or 
could be), talk of automating them seems premature to me.

> I suspect that the answer is "try to find developers willing to mentor".

Mentor what, exactly? If someone came along whose expertise and interest was 
solely in regression testing, and they wanted desperately to contribute to 
Lilypond, we should put them in that job [only?] — the amount of "mentoring" 
would essentially be zero, since [if the correct systems and processes were in 
place] they could do their job without doing literally any other task (i.e., 
someone else would provide them with a compiled binary in any desired version, 
someone else would take their regression test results and interpret and/or 
upload them, etc.).

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: ’Pond Jobs & Their Descriptions

[Graham Percival]

On Wed, Feb 05, 2020 at 06:55:38PM -0500, Kieren MacMillan wrote:
> 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?

If you want "extreme granularity", then wouldn't that be the whole
Contributor's Guide?

> If not, I’ll start a list, brainstormed from my naïve perspective.

I suspect that you want a "less extremely granular" list, in which
case I suggest:
  1) summarize the jobs that are described in the CG
  2) check if those descriptions are still accurate

> (b) identify the most important gaps or under-addressed areas in the 
> pipeline; and

I suspect that "automation tools" would be the most impactful
improvements.

> (c) help new developers find the best way in to the 'Pond.

I'm not up to date on current LilyPond, but I suspect that the
answer is "try to find developers willing to mentor".

Cheers,
- Graham

Re: ’Pond Jobs & Their Descriptions

[Carl Sorensen]

On 2/5/20, 4:55 PM, "lilypond-devel on behalf of Kieren MacMillan" 
 wrote:

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 
, 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?

Sounds like a great idea.  This is something that Graham did exceptionally well 
when he was here, IMO.

More sources:

 http://lilypond.org/doc/v2.19/Documentation/contributor/meisters
http://lilypond.org/doc/v2.19/Documentation/contributor/the-bug-squad


Carl

Re: ’Pond Jobs & Their Descriptions

[David Kastrup]

Kieren MacMillan  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
> , 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

’Pond Jobs & Their Descriptions

[Kieren MacMillan]

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 
, 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?
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info