’Pond Jobs & Their Descriptions

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

’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 <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?
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

David Kastrup
Kieren MacMillan <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Carl Sorensen-3
In reply to this post by Kieren MacMillan


On 2/5/20, 4:55 PM, "lilypond-devel on behalf of Kieren MacMillan" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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 <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?

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

   

Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Graham Percival-3
In reply to this post by Kieren MacMillan
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

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by Carl Sorensen-3
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by David Kastrup
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by 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 <here> and <here> and <here>).
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: <Lilypond code style guide here>, <good auto-formatting tools here>, 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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Graham Percival-3
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 <here> and <here> and <here>).
> 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: <Lilypond code style guide here>, <good auto-formatting 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

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Urs Liska-3
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: [hidden email]
>
>


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Jonas Hahnfeld
In reply to this post by Kieren MacMillan
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 <here> and <here> and <here>).
> 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: <Lilypond code style guide here>, <good 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.

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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Han-Wen Nienhuys-3
In reply to this post by Kieren MacMillan
On Thu, Feb 6, 2020 at 2:40 AM Kieren MacMillan <
[hidden email]> 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 - [hidden email] - http://www.xs4all.nl/~hanwen
Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by Urs Liska-3
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by Han-Wen Nienhuys-3
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> 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 <here> and <here> and <here>).
>> 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: <Lilypond code style guide here>, <good
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by Jonas Hahnfeld
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Kieren MacMillan
In reply to this post by David Kastrup
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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ’Pond Jobs & Their Descriptions

Wols Lists
In reply to this post by Kieren MacMillan
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

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]


12