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