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