lib/Catalyst/Manual/DevelopmentProcess.pod

   1 =head1 Catalyst Development Process
   2
   3 Below you will find information related to the Catalyst Development Process
   4
   5 =head1 Aims of the Catalyst Core Team
   6
   7 The main current goals of the Catalyst core development team continue to
   8 be stability, performance and a more paced addition of features, with a
   9 focus on extensibility. Extensive improvements to the documentation are
  10 also expected in the short term.
  11
  12 The Catalyst Roadmap at http://dev.catalyst.perl.org/roadmap will remain
  13 as is, and continues to reflect the specific priorities and schedule for
  14 future releases.
  15
  16 =head1 Charter for the Catalyst Core Team
  17
  18 =head2 Intention
  19
  20 The intention of the Catalyst Core Team is to maintain and support the
  21 Catalyst framework, in order for it to be a viable and stable framework
  22 for developing web based MVC applications. This includes both technical
  23 decisions about the Catalyst core distribution, and public relations
  24 relating to the Catalyst Framework as a whole.
  25
  26 The main priority for development is stability for the users of the framework,
  27 while improving usability and extensibility, as well as improving documentation
  28 and ease of deployment.
  29
  30 =head2 Membership
  31
  32 The Catalyst Core Team consists of the developers that have full commit
  33 privileges to the entire Catalyst source tree.
  34
  35 In addition, the core team may accept members that have non-technical roles
  36 such as marketing, legal, or ecconomic responsibilities.
  37
  38
  39 At the time of conception, the Core Team consists of the following people:
  40
  41 =over 4
  42
  43 =item Andy Grundman
  44
  45 =item Christian Hansen
  46
  47 =item Brian Cassidy
  48
  49 =item Marcus Ramberg
  50
  51 =item Jesse Sheidlower
  52
  53 =item Matt S. Trout
  54
  55 =item Yuval Kogman
  56
  57 =back
  58
  59 New members of the Core Team must be accepted by a 2/3 majority by the
  60 current members.
  61
  62 =head2 Technical Decisions.
  63
  64 Any change to the Catalyst core which can not be concieved as a correction of
  65 an error in the current feature set will need to be accepted by at least 3
  66 members of the Core Team before it can be commited to the trunk (which is
  67 the basis for CPAN releases). Anyone with access is at any time free to make
  68 a branch to develop a proof of concept for a feature to be committed to trunk.
  69
  70 =head2 Organizational and Philosophical Decisions.
  71
  72 Any such decision should be decided by majority vote. Thus it should be a
  73 goal of the organization that its membership number should at any time be
  74 an odd number, to render it effective with regards to decision making. The
  75 exceptions to this rule are changes to this charter and additions to
  76 the membership of the core team, which require 2/3 majority.
  77
  78 =head2 CPAN Releases
  79
  80 Planned releases to CPAN should be performed by the release manager, at the
  81 time of writing Marcus Ramberg, or the backup release manager, at the time
  82 of writing Andy Grundman. In the case of critical error correction, any member
  83 of the Core Team can perform a rescue release.
  84
  85 =head2 Public statements from the Core Team
  86
  87 The Core Team should strive to appear publicly as a group when answering
  88 questions or other correspondance. In cases where this is not possible, the
  89 same order as for CPAN Releases applies.
  90
  91