Nat "Is pm for Project Management or Perl Module" Torkington wrote:
> You're right that it's very unclear how RFCs will be accepted or
> rejected. It's become obvious from the variety of RFCs proposed that
> Perl cannot be designed by committee. That's why there's one person
> designated as the language architect: Larry. He's said he'll be
> grouping the RFCs into "definitely accept", "maybe", and "definitely
> reject" (perhaps more shades of "maybe" there). I think he'll also
> be coming up with suggested changes of his own: he's been working on
> formal interfaces, I know.
I would like to suggest that these various shades correspond
directly to the amount of time that will be spent discussing them in
the Perl community's feedback period on Larry's design. "Definitely
reject" should have little or no time devoted to it. (Perhaps just a
week, so anyone who is interested enough and passionate enough to
complain can raise a flag, but we all move on if no one is swayed.)
"Definitely accepts" should immediately proceed into a request for
prototypes phase, along with feedback from anyone who wants to
complain that they shouldn't be implemented. "Maybes" would have some
limited time for discussion of merits.
Major proposals that are accepted or likely maybes should have
assigned working groups from the get-go. (Nat, please read Larry's
mind during the language design phase and be ready to have the lists
set up. :) For the others, working groups *will not work*; everyone
always says their mind before the working groups are set up. Perhaps
perl6-maybe, perl6-reject, etc. lists would be in order, though. As
long as there are hard deadlines.
> I've been thinking about how to structure design and development in
> such a way that any given task is being worked on by only a few
> people. When the possibility for parallel development comes up (e.g.,
> fleshing out the language specification and the test cases), I'm
> trying to see how to let lots of people work on it without having the
> email flood of the current mailing lists. This isn't something I'm
> going to pull out of my ass: I'm sending these messages because I want
> everyone to be able to suggest and improve the development process.
>
> I've been thinking that getting the approach roughed out takes
> precedence over picking teams. You wouldn't know what you were being
> picked for, for a start. There's definitely an art in deciding who
> should work on what. If you have advice and suggestions, give 'em up,
> baby!
>
> I'm trying to shine the flashlight into the future and guess at how
> development should/will proceed. If *anyone* has suggestions or
> advice for this, let 'em rip. This isn't a vacuum, this isn't
> management by fiat, this is a group effort.
I believe in having small control teams (2-3 people) assigned to
each issue; these teams act as moderators for whatever they are
implementing. These teams consist entirely of proven people. Give
the control teams whatever they need to function: read-only + public
mailing lists, etc. Everyone else requests to work with one or more
groups (requests should go either to centralized project management or
to the group itself, I'm not sure which).
A degree of formality for code reviews and "apprenticeships" would
be good.
> Risk: That not being selected for a team will offend developers,
> causing them to leave.
If the above idea is played out right, the main people who will be
selected for the control teams will be people whose names are either
all over p5p, the perl5 source itself, or the covers of Perl books.
The rest of us shouldn't be offended; if we are, we should go sulk
somewhere and try to create something better than Perl on our own.
> What we're doing about that:
> * identifying tasks (e.g., filling in specifications and test cases?)
> can be done by as many who want
Those of us who haven't proved ourselves in some way through prior
association with Perl should be resigned to proving ourselves with
some smaller things before being handed the reins to anything.
Perhaps a semi-formal approval process would include generating a
certain amount of documentation (possibly external, or possibly
internal), a certain number of test cases, a working patch for
something minor, and so on, all reviewed and approved by offical
control team delegates, of course.
Perhaps the list of tasks that each control team has can be ranked
and new developers must start with a low-level task and seek approval
to move up. Or perhaps this opens the way to favoritism and
dictatorship. I don't think so, though.
J. David
