Index: docs/book/ch01_overview.pod
===================================================================
--- docs/book/ch01_overview.pod	(revision 27393)
+++ docs/book/ch01_overview.pod	(working copy)
@@ -7,61 +7,79 @@
 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.
+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 was a
+(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. 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.
+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 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 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 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
+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 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
+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 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.
+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.
 
-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.
+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
-Parrot project is quite different from managing a commercial project of
+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.
+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.
 
-This is a list of project roles, with a partial list of the folks who have
-taken responsibility for them.
+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>
@@ -72,25 +90,26 @@
 
 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
+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.
+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 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.
+The Pumpking has primary responsibility for the project source. As the lead 
+developer the Pumpking reviews patches, defines coding standards, and assists 
+the efforts of Committers and Contributors. The Pumpking also helps to develop
+and maintain the release schedule with the Architect and Release Managers. 
+There have been several Pumpkings, and the turnover rate is relatively high
+to prevent burnout.
 
 =item Release Managers
 
-Release managers have responsibility for executing a product release,
+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.
 
@@ -145,42 +164,53 @@
 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.
+either by being nominated by another Committer, or by requesting it.
 
 =over 4
 
 =item Core Developer
 
-Develops and maintains core subsystems (e.g. IO, Exceptions).
+Core Developers develop and maintain core subsystems such as the IO subsystem,
+the exceptions system, or the concurrency scheduler.
 
 =item Compiler Developer
 
-Develops and maintains one or more Parrot compilers (e.g. IMCC, PGE, TGE).
+Compiler Develoeprs develop and maintain one or more Parrot front-end 
+compilers such as IMCC, PIRC, PGE and TGE.
 
 =item High Level Language Developer
 
-Develops and maintains one or more High Level Languages (e.g. Tcl, Lua, 
-Perl 6).
+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
 
-Maintains and extends configure and build subsystems. Reviews smoke reports
-and attempts to extend platform support.
+Build Managers maintain and extend configuration and build subsystems. They
+reviews smoke reports and attempt 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
+Developing, maintaining, and extending test suite coverage and testing tools 
+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 Platform Porter
 
-Develops and maintains installation packages on various platforms.
+Parrot doesn't install itself, and many users are not familiar with with the 
+various build tools to do the job manually. Tt's the job of the Platform 
+Porters to ensure that working installation packages are available and 
+properly maintained for 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.
+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
 
@@ -194,18 +224,24 @@
 
 =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.
+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
-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.
+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
 
@@ -224,21 +260,29 @@
 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.
+duplicated effort minimal, and ensuring that 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
+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>.
+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 list via Google Groups at
+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>
-The following web sites have all the Parrot information you need:
+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
 
