=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? The plan for Parrot
formed 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 was a
contrived interview with Larry Wall and Guido van Rossum detailing
their plans to merge Python and Perl into a new language called
Parrot. A few months later, when Perl 6 internals began to take an
independent path within the larger project, they dubbed the subproject
"Parrot" in a fitting turn of life imitating art.

The plan for Parrot was to build a language-neutral run-time
environment. It would support all the features of dynamic languages
such as Python, Ruby, Scheme, Befunge, and others. It would have
threading and Unicode support (two of the most problematic features to
add into Perl 5 code) designed in from the start. It would support
exceptions and compilation to bytecode, and have clean extension and
embedding mechanisms.

The language-neutral interpreter was originally just a side effect of
good design. Keeping the implementation independent of the syntax
would make the code cleaner and easier to maintain. One practical
advantage of this design 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 will
be used in a large software project is a common planning problem.
There's never a perfect fit. It usually boils down to picking the
language with the most advantages and the least noticeable
disadvantages. The ability to easily combine multiple languages within
a project could be a huge benefit. Use well-tested libraries from one
language for one task. Take advantage of a clean way of expressing a
particular problem domain in a second, without being forced to use it
in areas where it's weak.

The modular design also benefits future language designers. Instead of
targeting I<lex>/I<yacc> and reimplementing low-level features such as
garbage collection and dynamic types, designers can write a parser
that targets the Parrot virtual machine.

As is typical of open source development projects, managing the
Parrot project 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.

This is a list of project 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 design documentation of project subcomponents
may be given to other members of the Project Team, or may be held jointly.
The Architect also works with the Pumpking and Release Managers to develop and
maintain the release schedule. Allison RandalX<Randal, Allison> leads the 
Parrot project as chief architect.

=item Pumpking

The Pumpking has primary responsibility for the project source. The Pumpking
is the lead developer, and as such reviews patches, defines coding standards,
and assists the efforts of Committers and Contributors. The Pumpking also
develops and maintains the release schedule with the Architect and Release
Managers. Chip SalzenbergX<Salzenberg, Chip> is the current pumpking.

=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 Architect and the Pumpking.

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 and Pumpking are Metacommitters, 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 asking for it.

=over 4

=item Core Developer

Develops and maintains core subsystems (e.g. IO, Exceptions).

=item Compiler Developer

Develops and maintains one or more Parrot compilers (e.g. IMCC, PGE, TGE).

=item High Level Language Developer

Develops and maintains one or more High Level Languages (e.g. Tcl, Lua, 
Perl 6).

=item Build Manager

Maintains and extends configure and build subsystems. Reviews smoke reports
and attempts to extend platform support.

=item Lead Tester

Develops, maintains, and extends test suite and testing tools. Responsible
for testing goals, including complete coverage of core components on targeted
platforms.

=item Platform Porter

Develops and maintains installation packages on various platforms.

=item Patch Monsters

Reviews and applies patches submitted by general contributors, keeping an eye
on 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

Fixes failing tests, makes sure coding standards are implemented, reviews
documentation and examples. A class of tickets in the tracking system (RT) has
been created for use by this group. This position encompasses tasks from entry
level to advanced, and is a good way to get 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
ways. All volunteer contributions are appreciated and recognized. All
volunteers who contribute to a file in the Parrot repository may add their
name to the F<CREDITS> file.

=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 making sure the job gets done.

=head2 Where to go

X<Parrot;mailing lists>
The mailing list for parrot is parrot-porters.  Subscribe by sending mail to
U<perl6-internals-subscribe@perl.org>. It 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>.

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

X<Parrot;sites>
The following web sites have all the Parrot information you need:

=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