Re: Perl Apprenticeship Program

On Wed, 31 Dec 1969, David Grove wrote:
> Ok, it sounds like a plan. Where do we start? By creating a registry of
> current tasks and masters, then fighting for apprenticeship?

I don't know.  I've gotten a few good responses on the general idea and
process, but little-to-no feedback on the individual suggestions.  I know
there's got to be a brick wall or two in there somewhere; I'd like to ID them
before committing to a particular path.  Perhaps some of this has been tried
before with p5p - I didn't start lurking until a year, year and a half ago. 
Perhaps some of this has been tried on other projects.  What worked?  What
tanked?  Specifics.

 > 
> We haven't really defined what qualifies a master or apprentice yet,
> though. That was left sort of open. I think solidifying it would be
> helpful.

I don't think *anything* is going to be rock-solid.  Here's a couple firm
starting points, though.

- If you only claim to be an apprentice, or want to apprentice, you're not a
master.  Obviously.

- Start with the p5 porters who have been active and are willing.  Most of
them, from what I've seen, have been willing to admit when there's been code in
Perl 5 that's outside their realm - they should have no problem doing the same
for Perl 6.  Even if they *aren't* Masters of Fooery, we need *some* direction,
and something in the same general direction of Perl 5 is a good start.

- If that doesn't fill up the ranks, then start pinging on your outside
volunteers.  Find the Subject Matter Experts.  (A compiler guru, a regex guru,
etc, even though they may be weak on Perl internals.  After all, Perl 6 doesn't
have any yet.)  That should help balance subject knowledge and TMTOWTDI with
the Perl tradition and legacy.  I suspect that this will be self-promoting,
but I'd expect that the list-chairs or Nat might grill volunteers for background
or abilities.  As I said in my original post, I'm not very fond of databasing
every person's professional history.

- Leave the various arenas fairly open at first.  Allow the volunteers to sort
themselves out naturally - the good ones should bubble to the top.  Only once
there's been "natural selection" in one area, should the groups start to choke
down on input to that area.  (This should obviously repeat for *each* area.)

At Nat just said, let's not get hung up in semantics.  This is, fundamentally,
no different than how p5p worked: a nug starts lurking, asking occasional
questions, providing occasional answers, graduates to suggesting patches to
docs and code, until they are eventually the ones driving the boat.  All I'm
really looking to do is a) getting as many people that want to be involved
involved, and b) trying to make the initial hurdle of getting involved not so
high.  Umm, maybe b more than a, since b -> a over the long run.

> What predisposes a person to the top of a list for apprenticeship in an
> area (RTFM should probably top this list)? Charming personality? Basic
> comprehension certainly, but what else?

I hope it's not charming personality.  I'll never get to do anything.

It may be as simple as self selection, ie, "I think this would be better
implemented as a gork2 call."  "Okay, then write us a gork2 call."

It may be group selection, ie, "You know, Billy Bob seems to have a lot of
good insights, let's see if we can get him a little more involved."

It may be luck of the draw, ie, "First come, first serve gets to document
foo()."

I think that there'll be so much to do, that we don't have to worry about
starving folks at the bottom of the list.

 -- 
Bryan C. Warnock
RABA Technologies