Perl Apprenticeship Program

Hmmm, both long *and* late.  Network outages are never a good thing.
This was promised this weekend, but I couldn't get it out.  It's a
little long: actual ideas and proposals begin around "Perl Masters."

-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The Perl Apprenticeship Program: Developing Perl Developers

In the not-so-grim past -
http://www.mail-archive.com/[email protected]/msg00106.html, to be
specific - Alan Burlison suggested an apprenticeship program be
established to, and I'll paraphrase heavily here, accomplish three
major goals:

1) Improve the overall quality of Perl 6.  By limiting the design and
implementation of critical sections to a small(ish), established core
team, Perl 6 would not suffer from ill-advisable or incomplete attempts
by well-intentioned, but otherwise ignorant, volunteers.

2) Solidify the future of Perl's development and maintenance base.  By
coupling experienced Perl developers with those new to the scene, the
community will be taking a step to grow its own support cadre from
within, as opposed to forcing them to make that transition on their
own.

3) Allow wider community involvement.  Perl development is more than
internal development.  There is documentation to document; there are
scripts to script; there are tests to test.  More than peripheral,
these tasks are an excellent way for a broad range of people to be able
to contribute to the cause, as well as good starting point for those
who wish to delve deeper.  There should be nearly as varied a set of
developers *of* Perl as there as developers *with* Perl.

There were two major decisions associated with the Perl 6 start-up that
makes *now* a good time to start a Perl Apprentice program.  The first,
and most obvious, decision was to explicitly make Perl 6 a community
effort.  Although previous Perls were open to the public, there was
never quite the "call to arms" that there was with Perl 6.  And whether
the response was less than expected or overwhelming, there *was* a
response.  And both the old and the new have encountered frustrations
because of it.  It is, I should hope, the community's desire and
expectation that Perl should continue to grow with new features, new
technology, new users, and new contributors.  What is unmanageable now
will surely become more so.

The second decision was to formally split Perl development on logical
boundaries.  For Perl 5, for instance, even though a subsection (such
as regular expressions) had its own experts and champions, the entire
support experience was still centered around the encompassing p5p
group.  It very nearly forced learning the whole to concentrate on a
single part.  The proposed segregation of various sections and
subsections of Perl 6 can limit the amount of required learning to the
very core of Perl, allowing more people to bring what they *do* know to
the Perl effort more quickly.  Furthermore, the several smaller
sections can allow an apprenticeship program itself to be developed -
first, by allowing a relatively isolated trial run; and second, by
allowing each section to tailor the program to its own needs.

Will it work?  The growth and dispersal of the development effort is
critically dependent on having the people necessary to keep it that
way. The more people that are forced to work in multiple areas of Perl,
the closer those areas get to one another, until critical mass is
reached and Perl 6 is simply, from a support perspective, Perl 5 + 1.

So what, exactly, is an Perl Apprentice?

In the earliest of days, apprenticeships were more often than not
gained by physical (or mental) prowess, traditions and customs, and/or
parental choice.  In fields as diverse as blacksmiths, medicine men,
and Jedi Knights, the apprentice-to-be merely needed to be raw material
able to emerge alive and able on the far end of a rather lengthy term
of servitude.  

Later, with the establishment of trade schools and guilds, just plain
raw material no longer sufficed.  Now one had to be raw material with
money.  

Eventually, as the overall level of worldly knowledge increased, and
the truly gifted artisans and craftsmen rose high above their
predecessors, it became necessary to have the fundamental knowledge of
the field in order to learn from "one in the know."

Apprentices would start small, usually by doing various menial tasks
and following around the master during the normal course of business. 
Over time, the apprentice's responsibilities would grow to handling
various parts of the craft itself.  After completing a number of years
under the tutelage of a master, the apprentice would set out on his
own, sufficient enough to survive, and hopefully to thrive. 
Eventually, as reputations spread, new apprentices would seek the
apprentice-turned-master, and the cycle would continue.

Or something like that.  In any case, this last example is closest to
the model of apprenticeship that Perl needs.  The Perl
Apprentice-To-Be's need a fundamental understanding of the underlying
technology that they will be expected to further develop.  The current
Perl Masters need to develop those fundamental skills so that they are
Perl oriented.

In Perl-speak, that may mean starting up with secretarial skills, and
moving to documentation, Q&A forums, testing, and simple component
coding.  The rest of this excruciatingly lengthy document is a series
of ideas and suggestions as to how Perl 6 could put an apprenticeship
program into use.  It has been modified to reflect some of the recent
posts to the groups.

Perl Masters

Perl Masters (not to be confused with Perl masters) should be composed
of an entirely voluntary force.  Let's face it, everyone has a different 
level of tolerance and patience for the ignorant.  For some, it's zero.  
No one should be forced to play along.

Perl Masters should be comprised of Perl masters, who will largely be
self-nominated, with consensus provided from the other central gurus. 
This means the initial seed of the group will need to somehow gel into
place - somehow, I don't think that's a problem.  p5p is a good place
to start.

Masters should also be able to choose if they want to mentor someone
directly, or take advantage of a "group apprentice."  In other words, a
Master can decide to drag around a couple of dedicated apprentices to
do his or her dirty work, or relegate items to a handful of general
apprentices assigned to the group as an entity.  Either method has its
advantages and disadvantages, and it's entirely a matter of personal 
preference.

As a potential apprenticeship program - not necessarily the one below -
develops, there is probably no reason an person can't master in one area, 
but apprentice in another.

Perl Apprentices

Apprenticeship should also voluntary, as should the area a person wants
to apprentice in.  This is not to say that everyone will get their
wish, or won't be asked to move aside or step down.  If an apprentice
wishes to apprentice in, say, installation procedures, but only the
English documentation, he or she may be asked to reconsider if written
English skills aren't really a forte.  (For instance, how about writing
the documentation in Language X, which he or she is native in?)

Apprentices should also expect to start small.  A volunteer may want to
help design and code the regexp engine, for example, but may start by
writing weekly summaries of the regexp working group.

And, unfortunately, some apprentices should also expect to be, um,
asked to apprentice in a different area.  Don't take it personally,
(unless, of course, it *is* personal :-).

Registering

Here's where it gets fuzzy.  I'm not overly fond of a centralized
registry of folks and their skill sets.  But coordination would
probably be easier if *some* list(s) existed somewhere.  So I'll
present a couple of possibilities.

No registry - every task destined for an apprentice will need to be
"bid on" by every interested party.  Although each task is likely to
get an interested (and current) person, excess traffic will be
generated, and may make it more difficult to manage tasks across all of
Perl.

Section registry - each section of Perl maintains its own list, along
with whatever information is necessary (such as language fluency for
documentation and platform availability for testers).  The list chairs
would be a good person to set this up.  Work can be distributed among
the volunteers within that group, and it's a little easier to manage
work across the whole of Perl.

Central registry - Perl has a single volunteer list that the various
groups can pull from.  This list might be segregated by what they want
to do - coding, testing, etc.  I suspect that this would eventually
degrade into a section registry scheme.

Apprentice Tasks

Any task vaguely Perl related can be apprenticed out.  Here is a sample
list:

- Documentation, both internal and external, including, for instance,
programming guides, DDDs, user documentation, API documentation, coding
standards, etc.

- Writing weekly summaries of the groups and other stuff the list chair
is currently doing (or should be doing).

- Q&A or "Help Desk" between working groups, or between a working group
and a public forum.

- Writing test code, both internal and external.

- Fleshing out simple stub code.

- Research and prototyping.

- Mananging new apprenctices, or the program itself.

Example

I'll give an example scenario based on Nat's suggestion of ten gurus
working on the Internals API.  This is an example, and only an
example.  Attributed behavior is "for example" only.  Example, get it?

Nat and Dan pick ten people to begin work on the API design.  Of the
ten, Nick decides that he's going to grab a couple of volunteers to be
his apprentices, Simon decides that he wants no part of the whole
thing, and everyone else is ambivalent.  Dan also picks three other
volunteers to be a general pool of apprentices for the group.

One apprentice is told to write up a weekly summary of the topics,
document it fully, and send it to the group, Nat, Larry, and the public
list.  Another apprentice is told to monitor the public list, answer
any questions he or she is able, and write up a weekly summary of the
feedback and questions to give to the group.

One day, Nick, Simon, and Andy get into a heated discussion about whether 
foo can really bar the work the way gork can.  Across all platforms.  
Dan gives them a week to come up with some benchmarks.

Simon codes his implementation of foo, documents his findings, etc. 
Nick codes his implementation of metafoo, farming off the coding of
some of his trivial stubs to one of his helpers.  Andy codes a foo-gork
comparison test, asking Dan to have one of the group apprentices do the
actual benchmarking, since he'll be too busy with something else.  Dan
then pings on one of the group apprentices to grab the code and run the
tests.

Truncation station.  Feedback?  On track, or waaaaaaaaaaaay off base?

-- 
Bryan C. Warnock
RABA Technologies