Catalyst::Manual::DevelopmentProcess - Administrative structure of the Catalyst
The main philosophy behind Catalyst development can be summarized as:
Everyone is welcome (and will be encouraged) to contribute to Catalyst in
whatever capacity they're able to. People in #catalyst-dev will be more than
happy to talk newcomers through contributing their first patch, or how best to
go about their first CPAN extension module....
<http://wiki.catalystframework.org/wiki/#Community> has information about
how to get in touch with the Catalyst "community". In particular,
you would want to discuss a proposed change on the mailing list:
or on IRC:
Usually, the core team will be more than happy for you to contribute, and will
talk you through how to submit a patch, or get a "commit bit".
The Catalyst git repository can be found at:
The Catalyst subversion repository can be found at:
There is no dated release cycle for Catalyst. New releases will be made when
sufficient small fixes have accumulated; or an important bugfix, or
significant feature addition, is completed.
The Catalyst Roadmap is kept at
The TODO list with known bugs / deficiencies is kept at
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 current goals of the Catalyst core development team are stability,
performance, and a properly paced addition of features, with a focus on
The core team is concerned with the 'core' Catalyst distributions (i.e.
Catalyst::Runtime, Catalyst::Devel and Catalyst::Manual), and also tries to
encourage best practices for extension authors, and cooperation and shared
vision within the Catalyst community.
The Catalyst Core Team consists of the developers who have full commit
privileges to the entire Catalyst source tree, and who have made a significant
contribution to the core Catalyst distributions, and various extensions and
In addition, the core team includes members that have non-technical roles, such
as marketing, legal, or economic responsibilities.
Currently, the Core Team consists of the following people:
- Brian Cassidy
- Andy Grundman
- Christian Hansen
- Yuval Kogman
- Marcus Ramberg
- Jonathan Rockway
- Jesse Sheidlower
- Matt S. Trout
- Florian Ragwitz
- Tomas Doran
New members of the Core Team must be accepted by a 2/3 majority by the current
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 committed to master (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 master.
Any organizational or philosophical 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.
Planned releases to CPAN should be performed by the release manager, at the time
of writing Marcus Ramberg, or the deputy release manager, at the time of
writing Florian Ragwitz. In the case of critical error correction, any member
of the Core Team can perform a rescue release.
The Core Team should strive to appear publicly as a group when answering
questions or other correspondence. In cases where this is not possible, the
same order as for CPAN releases applies.
As Catalyst is deliberately designed for extension, there is an ecosystem of
several hundred Catalyst extensions that can be found on CPAN.
See Catalyst::Manual::ExtendingCatalyst for more information on how to extend
Catalyst in various ways and how to write CPANable components for Catalyst
which can be reused in many applications.
It is recommended to post a request for comments to the Catalyst mailing list,
or ask around in the #catalyst IRC channel before starting to implement
something, as another member of the community is likely to have example or
prototype code that you can reuse, and members of the community and core team
are happy to advise on the best way to implement a generic solution to a
This could save you duplicate work, and will help you produce a better thought
out and designed extension.
Catalyst Contributors, see Catalyst.pm
This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.