Having decided to start work on Perl 6, the first issue addressed was how to improve the development process. An examination of the existing process will underline why this was considered necessary.
Perl 5 development centred around one mailing list, perl5-porters, aka "p5p". This mailing list was home to a core group of perl hackers and an ever-changing procession of hopeful contributors, with Larry presiding over the whole thing as a benevolent, but mostly uninvolved, dictator.
The p5p list was very high volume, and many subscribers dropped off it when they were unable to keep up with the discussions. For those without the courage to brave the deluge, a weekly summary was posted on the web and available by email. This provided links to threads or specific posts of significant interest, all of which were available via a web archive.
As well as being high volume, p5p had a reputation for unfriendliness and for being the home to some particularly heated flame wars. Certain personalities on the list were renowned for the frequency and vehemence of their flames, and newcomers were often scared away by the argumentative atmosphere or the cold welcome they received.
More recently, a system of "refereeing" has been introduced, in which a small group of trusted regulars are charged with keeping the peace. The means at their disposal include out-of-band warnings to offenders and moderation of posters who repeatedly ignore warnings.
A number of reasons were given for why the Perl development process needed changing. These included:
Reverse p5p's bad reputation
Give everyone an opportunity to contribute -- not just the old-timers and Unix users, but also the Windows contingent, the WWW scripting crowd, and those who use Perl for purposes ranging from astronomical data-crunching to mainframe applications development
Record discussions and decisions for future reference, so that late joiners could read a clear archive of what had gone before
Apply a bit of real project management
Foster the kind of working environment that doesn't drive valuable people away
Straight after the TPC 4.0 meeting and announcement, a mailing list called perl6-bootstrap was set up, with the goal of determining what shape the subsequent process and community should take.
Unfortuneately, the bootstrap phase was given only a couple of weeks to make decisions, and the first week of that was largely wasted while travelling TPC attendees returned home, recovered from their jetlag, and caught up on their email backlogs.
The result was rushed decisions that upset some people. However, most of the people were upset because the decisions had been rushed, not because they were necessarily bad. Few suggestions were offered that differed significantly from what we ended up with -- most differences were in the naming of mailing lists and other such (relative) trivia.
Here's what the bootstrap list came up with:
Project manager: Nathan Torkington
Working groups, lead by WG chairs
Language (Kirrily Robert)
Internals (Dan Sugalski)
Standard Library (Graeme Barr)
Build (Jarkko Hietaniemi)
QA (Michael Schwern)
Licensing (Bradley Kuhn)
Each working group has a mailing list, and may spawn sub-lists (with chairs for each one) as required.
Working groups to develop RFCs describing possible changes to make in Perl 6. Note that these are actually "Requests For Comment", not fixed standards as IETF RFCs tend to be.
Larry would create an overall design for Perl 6 based on the best suggestions to come out of the RFC process.