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;
    &c &c &c.

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, &c 
&c &c. 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: address@hidden