[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ’Pond Jobs & Their Descriptions
From: |
Kieren MacMillan |
Subject: |
Re: ’Pond Jobs & Their Descriptions |
Date: |
Thu, 6 Feb 2020 08:24:21 -0500 |
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
- Re: ’Pond Jobs & Their Descriptions, (continued)
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/05
- Re: ’Pond Jobs & Their Descriptions, Graham Percival, 2020/02/05
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/05
- Re: ’Pond Jobs & Their Descriptions, Urs Liska, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Jonas Hahnfeld, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, David Kastrup, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Han-Wen Nienhuys, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions,
Kieren MacMillan <=
- Re: ’Pond Jobs & Their Descriptions, Wols Lists, 2020/02/06
- Re: ’Pond Jobs & Their Descriptions, Kieren MacMillan, 2020/02/06
Re: ’Pond Jobs & Their Descriptions, Janek Warchoł, 2020/02/08