From: Jesse Sheidlower Date: Sat, 20 May 2006 03:53:05 +0000 (+0000) Subject: Proofread! Wrap docs at 72 colums! X-Git-Tag: 5.7099_04~580 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Runtime.git;a=commitdiff_plain;h=155abf4b6a2aa70b0a81bb4c7f462867590d4de4 Proofread! Wrap docs at 72 colums! --- diff --git a/lib/Catalyst/Manual/DevelopmentProcess.pod b/lib/Catalyst/Manual/DevelopmentProcess.pod index 2e2a068..a62be00 100644 --- 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.