perl6-lang Project Management

[Michael Lazzaro]

I have a rather fundamental proposal.

The A's and E's represent the framework and major decisions for Perl6, but not every minor niggling issue and detail. As we keep seeing, there is no shortage of things to pin down. We need to do that, and we need to do it in the same rough order as the Apocalypses, and we need to do it _NOW_.

Larry and the rest of the design team are the ones leading the Perl6 language design. I hope, however, that they do not represent the sum total of the useful labor that can be applied to this process. The A's and E's, by themselves, are not sufficient documentation to fully guide the full implementation of the language, and I would surely hope that we're not intending to wait until Apocalypse 33 is completed before fully documenting the implications of Apocalypse 2. Rather than placing it at the feet of the design team to do in their no-doubt-voluminous spare time, I would expect that we could be helping more directly.

For the amount of discussion generated on this list, our overall contribution to the effort is less than it should be. Primarily because we're Discussing, and not Planning. It's great that we can ask questions, and get them answered, but who cares, when the next person has to ask the same $#@%$ thing?

The entire reason I'm writing those pages and pages of primitive docs is to thoroughly get into all the nooks and crannies of the language, and make sure every stick of it is as complete/simple/regular/obvious/intuitive as humanly possible. And to make sure that, somewhere, We Have It Written Down. But if you look at the pseudo-chapter I just posted -- which covers only a tiny fraction of Apocalypse 2 -- you will still see holes where rudimentary behaviors are, as of yet, unclear.

My proposal is this:

Let us (perl6-lang, with the help of Larry/Damian/etc) focus on fleshing out every last detail implied by Apocs 2-N, _in that order_. Let's not worry about the block constructs until we've got nearly all aspects of the operators down. Let's not worry about the operators until we've gotten the behavior of numeric, string, array, hash, etc. values and variables down. Yes, the ordering can never be exact because it's all interrelated. But we can accomplish _something_ towards the detailed, drop-dead accurate definition of all aspects of Perl6. Project Rule #1: IF IT ISN'T DOCUMENTED, IT ISN'T DONE.

If we can impose enough self-management to accomplish it, I am willing to help in the excruciating task of Writing Things Down, and in the even worse task of helping focus the process. But I can't, without help -- specifically, the willingness of the community to focus on individual areas one-by-one, so that we can close them out. There's just no way I can document anything right now -- we haven't made enough decisions to document.

So what say you? Can we migrate perl6-language into a list that finalizes aspects of the design, documents them, and revises them as needed, rather than our usual circular discussions of things already long-since past?

MikeL