[catagits/Catalyst-Runtime.git] / lib / Catalyst / Manual / DevelopmentProcess.pod

=head1 Catalyst Development Process

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
focus on extensibility. Extensive improvements to the documentation are
also expected in the short term.

The Catalyst Roadmap at http://dev.catalyst.perl.org/roadmap will remain
as is, and continues to reflect the specific priorities and schedule for
future releases.

=head1 Charter for the Catalyst Core Team

=head2 Intention

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
decisions about the Catalyst core distribution, and public relations 
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.

=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.


At the time of conception, the Core Team consists of the following people:

=over 4

=item Andy Grundman

=item Christian Hansen

=item Brian Cassidy

=item Marcus Ramberg

=item Jesse Sheidlower

=item Matt S. Trout

=item Yuval Kogman

=back

New members of the Core Team must be accepted by a 2/3 majority by the
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.

=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.

=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.

=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.
Commit	Line	Data
9b29b536	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