Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Friday May 18, 2001
06:39 PM

perl6 visibility

[ #184 ]
In a conversation with David Grove and others, I realized that the current web site isn't doing a very good job of communicating what the big picture of perl6 development is like, and where we are in that picture.

The big picture is that I view perl6 development as separate from maintenance. The development has played out like this:

  1. The community makes initial suggestions for changes. This was the RFC process.
  2. Larry chews on them and begins emitting a draft language design. This is the Apocalypse process.
  3. The community gives him feedback after each one, which may cause him to change some part of an Apocalypse.

The Apocalypses, after being modified by Larry with the community's feedback, will give us the final language design.

I suspect most people don't realize that this third stage is going on, and that their comments can influence Larry. One of my goals for next week is to make sure that folks know that the Apocalypses aren't fait accompli. They come from somewhere and they aren't the final word. Larry's not the Pope, and Rule #2 allows for that. (Rule #1 is that Larry's word is final. Rule #2 allows Larry to change his mind.)

This lack of communication has lead to a fear, I gather, that perl6 isn't involving the community. While it's true there's no voting process, that's by design not through the evil machinations of a Central Cabal.

It's good that Larry has ultimate say over the design of Perl. We're funnelling everyone's suggestions and experience through the most experienced language designer we have. If we were to take final control away from Larry, we'd end up with design by committee, and the results of that are never pretty.

There is a place for formal community structure, though. I'm picturing that once we have a Perl to maintain, maintenance will be done in a similar fashion to the FreeBSD system. That is, nobody can buy power and nobody can monopolize power.

While the precise details of perl's system can be worked out closer to when we'll need it, I hope it keeps the idea that you have to do stuff to be able to prevent stuff, without preventing people who want to do stuff from contributing and becoming part of the development community. One of the problems I see in the informal systems we have now is that good ideas and enthusiastic people can be filibustered and driven off by kibitzers who don't actually ever submit patches to Perl.

That's all for later, though. I've been trying hard to postpone that discussion--if we wanted to, we could easily spend the next four years talking about voting systems and structures. Hell, the USA's been doing it since 1776 and apparently still doesn't have it right :-)

For the time being I want to update the website to reflect where we are, what we can all do, and where we'll be going. Hopefully that'll settle some of the fear, uncertainty, and doubt that's going around.

Until next time,

--Nat