Proofread! Wrap docs at 72 colums!

diff --git a/lib/Catalyst/Manual/DevelopmentProcess.pod b/lib/Catalyst/Manual/DevelopmentProcess.pod
index 2e2a068..a62be00 100644 (file)
--- a/lib/Catalyst/Manual/DevelopmentProcess.pod
+++ b/lib/Catalyst/Manual/DevelopmentProcess.pod
@@ -5,7 +5,7 @@ Below you will find information related to the Catalyst Development Process
 =head1 Aims of the Catalyst Core Team
 
 The main current goals of the Catalyst core development team continue to
-be stability, performance and a more paced addition of features, with a
+be stability, performance, and a more paced addition of features, with a
 focus on extensibility. Extensive improvements to the documentation are
 also expected in the short term.
 
@@ -19,21 +19,21 @@ future releases.
 
 The intention of the Catalyst Core Team is to maintain and support the 
 Catalyst framework, in order for it to be a viable and stable framework
-for developing web based MVC applications. This includes both technical
+for developing web-based MVC applications. This includes both technical
 decisions about the Catalyst core distribution, and public relations 
-relating to the Catalyst Framework as a whole.
+relating to the Catalyst framework as a whole.
 
-The main priority for development is stability for the users of the framework,
-while improving usability and extensibility, as well as improving documentation
-and ease of deployment.
+The main priority for development is stability for the users of the
+framework, while improving usability and extensibility, as well as
+improving documentation and ease of deployment.
 
 =head2 Membership
 
 The Catalyst Core Team consists of the developers that have full commit
 privileges to the entire Catalyst source tree. 
 
-In addition, the core team may accept members that have non-technical roles
-such as marketing, legal, or ecconomic responsibilities.
+In addition, the core team may accept members that have non-technical
+roles such as marketing, legal, or ecconomic responsibilities.
 
 
 At the time of conception, the Core Team consists of the following people:
@@ -61,31 +61,33 @@ current members.
 
 =head2 Technical Decisions.
 
-Any change to the Catalyst core which can not be concieved as a correction of
-an error in the current feature set will need to be accepted by at least 3
-members of the Core Team before it can be commited to the trunk (which is
-the basis for CPAN releases). Anyone with access is at any time free to make
-a branch to develop a proof of concept for a feature to be committed to trunk.
+Any change to the Catalyst core which can not be conceived as a
+correction of an error in the current feature set will need to be
+accepted by at least 3 members of the Core Team before it can be
+commited to the trunk (which is the basis for CPAN releases). Anyone
+with access is at any time free to make a branch to develop a proof of
+concept for a feature to be committed to trunk.
 
 =head2 Organizational and Philosophical Decisions.
 
-Any such decision should be decided by majority vote. Thus it should be a 
-goal of the organization that its membership number should at any time be
-an odd number, to render it effective with regards to decision making. The
-exceptions to this rule are changes to this charter and additions to
-the membership of the core team, which require 2/3 majority.
+Any such decision should be decided by majority vote. Thus it should be
+a goal of the organization that its membership number should at any time
+be an odd number, to render it effective with regards to decision
+making. The exceptions to this rule are changes to this charter and
+additions to the membership of the Core Team, which require a 2/3
+majority.
 
 =head2 CPAN Releases
 
-Planned releases to CPAN should be performed by the release manager, at the
-time of writing Marcus Ramberg, or the backup release manager, at the time
-of writing Andy Grundman. In the case of critical error correction, any member
-of the Core Team can perform a rescue release.
+Planned releases to CPAN should be performed by the release manager, at
+the time of writing Marcus Ramberg, or the backup release manager, at
+the time of writing Andy Grundman. In the case of critical error
+correction, any member of the Core Team can perform a rescue release.
 
 =head2 Public statements from the Core Team
 
 The Core Team should strive to appear publicly as a group when answering
-questions or other correspondance. In cases where this is not possible, the
-same order as for CPAN Releases applies.
+questions or other correspondence. In cases where this is not possible,
+the same order as for CPAN Releases applies.