=pod

=head1 Project Overview

Z<CHP-1>

X<Parrot>
The heart of Parrot is a grandiose idea that turned out to be more
realistic than anyone originally could have believed: why not have a
single interpreter for several languages? Up till then, dynamic
languages such as Perl, Python, Ruby, and Scheme had all used their
own individual interpreters, which were often not easily extensible,
not modular, and not capable of interoperation. The solution was to
create a single virtual machine for all such languages, a virtual
machine called Parrot. The planning for Parrot progressed slowly, in
bits and pieces, over the period of a year.

On April 1st, 2001, Simon CozensX<Cozens, Simon> published an article
titled "Programming Parrot" as an April Fools' joke
(U<http://www.perl.com/pub/a/2001/04/01/parrot.htm>).  It contained a
contrived interview with Larry Wall and Guido van Rossum detailing
their plans to merge Python and Perl into a new language called
Parrot. This was plausible because both languages were undergoing
massive redesigns: Perl was being rewritten as "Perl 6", and Python
was being reconsidered as "Python 3000". A few months later, when the
Perl 6 internals project began to take an independent path from the
rest of the Perl 6 design effort, they dubbed the subproject "Parrot"
in a fitting turn of life imitating art.

The goal for the Parrot project was to create a language-neutral run-time
environment for dynamic languages like Perl and Python. It would support
all the features of those and other dynamic languages such as Ruby,
Scheme, Befunge, PHP, and others. Threading and Unicode would be supported
from the start, mitigating two thorns that had plagued Perl 5 developers for
years. A robust exceptions system, a capability to compile into
platform-independent bytecode, and a clean extension and embedding mechanism
would be just some of Parrot's standard features.

The irony is that the language-neutrality of the interpreter was originally
just a side effect of good design. Keeping the implementation independent
of the syntax would make the codebase cleaner and easier to maintain.
One practical advantage of this was that Parrot development could begin even
though the Perl 6 language specification was still in flux.

The bigger win in the long term, though, was that since Parrot would
support the features of the major dynamic languages and wasn't biased
to a particular syntax, it could run all these languages with little
additional effort.  It's generally acknowledged that different
languages are suited to different tasks. Picking which language to use
in a large software project is a common planning problem. There's never a
perfect fit. The decision usually boils down to settling for the
language with the most advantages and the least noticeable
disadvantages. The ability to easily combine multiple languages within a
single project, something which is typically possible of most compiled
languages such as C but rarely possible with dynamic interpreted languages,
could be a huge benefit to developers. Using well-tested libraries from one
language, taking advantage of clean problem-domain expression in a second,
and using languages according to their inherent strengths is the ultimate
goal, one which is only becoming possible through Parrot.

Modular design also benefits future language designers, not just designers of
current languages. Instead of targeting I<lex>/I<yacc> and reimplementing
low-level features such as garbage collection and dynamic data types,
designers can leave the details to Parrot and focus on the high-level features
of their language: syntax, libraries, capabilities. Parrot does all the
necessary bookkeeping, exposing a rich interface with capabilities that few
languages can make full use of.

As is typical of open source development projects, managing the
development of Parrot is quite different from managing a commercial project of
the same size and complexity.  There are no schedules, no deadlines, no
hiring and firing, and no salaries, bonuses, or stock options. There are
no employees or bosses; there is very little hierarchy whatsoever.
Management in this context isn't about giving orders, it's about making
sure everyone has what they need to keep moving forward. Like most open-source
and open-content projects, the best leadership is to set a good example and
stay out of the way.

The Parrot development team is broken down into several distinct roles, which
people assume according to their merits and their talents. This is a list of
those roles, with a partial list of the folks who have taken responsibility
for them.

=head2 Project Team
X<Project Team>

=over 4

=item Architect

The architect has primary responsibility for setting overall direction of the
project, and to facilitate team communication and understanding of
architectural issues. The architect is primarily, but not solely, responsible
for making design decisions and documenting them in Parrot Design Documents;
responsibility for design and documentation of project subcomponents may be
delegated to other members of the Project Team, or may be held jointly.
The Architect also works with the Release Managers to develop and
maintain the release schedule. Allison RandalX<Randal, Allison> leads the
Parrot project as chief architect.

=item Release Managers

Release managers have responsibility for executing a product release
according to the release schedule. The release schedule is developed and
maintained jointly with the project Architect.

Current release managers are, in this order:

    Jerry Gay
X<Gay, Jerry>
    Patrick Michaud
X<Michaud, Patrick>
    Matt Diephouse
X<Diephouse, Matt>
    Will Coleda
X<Coleda, Will>
    chromatic
X<chromatic>
    Allison Randal
X<Randal, Allison>

Information on the release procedure can be found in
F<docs/project/release_manager_guide.pod>.

=item Metacommitter

All Metacommitters are responsible for managing commit access to the Parrot
repository. Once the Architect or Pumpking approves a request for a
Contributor to be given commit access, a Metacommitter provides that access.
The Architect is a Metacommitter, but other Project Team members
may also hold this role.

Current metacommitters are:

    Allison Randal
X<Randal, Allison>
    Chip Salzenberg
X<Salzenberg, Chip>
    Jerry Gay
X<Gay, Jerry>
    Will Coleda
X<Coleda, Will>
    Jesse Vincent
X<Vincent, Jesse>

The procedure on how to manage the list of Parrot committers can be found in
F<docs/project/metacommiter_guide.pod>.

=back

=head2 Committers

X<Committers>
Contributors who submit numerous, high-quality patches may be considered to
become a Committer. Committers have commit access to the full Parrot
repository, but generally work only on one or more subprojects; Committer
categories are described below. Contributors may considered for commit access
either by being nominated by another Committer, or by requesting it.

=over 4

=item Core Developer

Core Developers develop and maintain core subsystems such as the IO subsystem,
the exceptions system, or the concurrency scheduler.

=item Compiler Developer

Compiler Develoeprs develop and maintain one or more Parrot front-end
compilers such as IMCC, PIRC, PGE and TGE.

=item High Level Language Developer

Developers who work on any of the high-level languages that target Parrot such
as TCL, Lua or Perl 6, are High-Level Language Developers. Many of these
language projects are located in the Parrot repository, although some are
maintained separately as well. It is the intention that all languages be
developed separately from Parrot before the 1.0 release.

=item Build Manager

Build Managers maintain and extend configuration and build subsystems. They
reviews smoke reports and attempt to extend platform support.

=item Lead Tester

Developing, maintaining, and extending test suite coverage and testing tool 
are the key tasks for the Lead Testers. Lead Testers are also responsible for
testing goals, including complete coverage of core components on targeted
platforms.

=item Patch Monsters

Hackers and developers submit patches to Parrot every day, and it takes a keen
eye and a steady hand to review and apply them all. Patch Monsters, as they
are affectionately known, are in charge of checking patches for conformance
with coding standards and desirability of features.

=back

A list of committers that have a role they've taken responsibility for can
be found in F<RESPONSIBLE_PARTIES>.

=head2 Contributors
X<Contributors>

=over 4

=item Cage Cleaners

Parrot's cage, the development working environment, has a tendency to get
messy and disorganized over time. It's the responsibility of the aptly-named
Cage Cleaners to ensure coding standards are followed, that documentation is
complete and accurate, that all tests are functioning properly, and that there
are plenty of coding examples for new users to learn from. A class of tickets
in the RT tracking system has been created especially for use by this group.
This position encompasses tasks that run the gamut from entry-level to
advanced, and is a good entry point for new users who want to get more
familiar with Parrot internals.

=item General Contributor

Contributors are volunteers who write code or documentation patches, take
part in email or online conversations, or contribute to the project in other
important ways. All volunteer contributions are appreciated and recognized,
with their names being added to the F<CREDITS> file in the Parrot
repository. When a new contributor submits patches which have been accepted,
they should add their name to this list.

=back

The list of general contributors can be found in F<CREDITS>.

=head2 Furthermore

X<Hansen, Ask BjE<oslash>rn>
X<Spier, Robert>
Last, but not least, is the glue that holds the project together. Ask
BjE<oslash>rn Hansen and Robert Spier manage the email, revision
control, and bug-tracking systems, as well as the web site for Parrot,
U<http://www.parrotcode.org>. Without these systems, the project would
grind to a screeching halt.

In the end, it is the developers themselves who hold the project
together. Individuals bear their own share of responsibility for
finding tasks that suit their skills, coordinating with others to keep
duplicated effort minimal, and ensuring that the job gets done.

=head2 Where to go

X<Parrot;mailing lists>
Mailing lists are an important tool for communication, and the Parrot
Development team maintains a special-purpose mailing list to coordinate the
efforts of the many team members. The mailing list for Parrot is called
"Parrot-Porters", and you can subscribe to it by sending a blank email message
to  U<perl6-internals-subscribe@perl.org>. The list is archived at
U<http://www.nntp.perl.org/group/perl.perl6.internals>
and available via NNTP at U<nntp://nntp.perl.org/perl.perl6.internals>.
Despite the presence of the term "perl6" in the list name, the list is not
used to talk about Perl 6. The name is just a historical throw-back to the
time when the Perl 6 and Parrot projects were operating together.

You can also read the Parrot-Porters list via Google Groups at
U<http://groups-beta.google.com/group/perl.perl6.internals>

X<Parrot;sites>
Parrot information and documentation can be accessed on the web in a variety
of locations. The following web sites should have all the Parrot information
you need to get started:

=over 4

=item * U<http://www.parrotcode.org>

=item * U<http://dev.perl.org/perl6>

=item * U<http://bugs6.perl.org>

=item * U<http://pugscode.org>

=back

=cut
