The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.


Moose::Manual::Contributing - How to get involved in Moose


Moose is a pretty open project and we are always willing to accept bug fixes, more tests and doc patches. Doing these things is as simple as cloning a copy of the git repository and hacking.

Commit bits are given out freely. All we ask is that for any non-trivial code patches, you check with one of the core developers before applying said patch.

Alternatively, you can make a new branch with your change and push it back to the Moose git server, then ask a core dev to review your branch.

IRC and Email

A lot of Moose discussion happens on IRC. We have two channels on, #moose and #moose-dev. The former is much more active, but the core developers pay attention to both channels.

We also have a mailing list, and all the core developers read and respond to messages on that list.


Moose already has a fairly large feature set and we are currently not looking to add any major new features to it. If you have an idea for a new feature in Moose, you are invited instead to create a MooseX module first.

At this stage, no new features will even be considered for addition into the core without first being vetted as a MooseX module, unless it is absolutely 100% impossible to implement the feature outside the core.

If you think it is 100% impossible, you're probably wrong. However, your feature may need a small hook in the core, or a refactoring of some core modules, and we are definitely open to that.

Moose was built from the ground up with the idea of being highly extensible, and quite often the feature requests we see can be implemented through a couple of small and well placed extensions. Try it, it is much easier then you might think.


If you write any code for Moose or Class::MOP, you must add tests for that code. If you do not write tests then we cannot guarantee your change will not be removed or altered at a later date.

If your code change/addition is deep within the bowels of Moose/Class::MOP and your test exercises this feature in a non-obvious way, please add some comments either near the code in question or in the test so that others know.

We also greatly appreciate documentation to go with your changes, and an entry in the Changes file. Make sure to give yourself credit!


Change is inevitable and Moose is not immune to this. We do our best to maintain backwards compatibility, but we do not want the code base to become overburdened by this. This is not to say that we will be frivolous with our changes, quite the opposite, just that we are not afraid of change and will do our best to keep it as painless as possible for the end user.

The rule is that if you do something that is not backwards compatible you must do at least one deprecation cycle (more if it is larger change). For really larger or radical changes dev releases may be needed as well (the core developers will decide on this on a case-per-case basis).

The preference with regard to deprecation is to warn loudly and often so that users will have time to fix their usages.

All backwards incompatible changes must be documented in Moose::Manual::Delta. Make sure to document any useful tips or workarounds for the change in that document.


Stevan Little <>


Copyright 2009 by Infinity Interactive, Inc.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.