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