Typo fix!

[gitmo/Moose.git] / lib / Moose / Manual / Contributing.pod

=pod

=head1 NAME

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

=head1 GETTING INVOLVED

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 away. All
we ask is that for any non-trivial code patches, you check with one 
of the core developers before applying said patch. 

=head1 NEW FEATURES

Moose already has a fairly large feature set and we are currently B<not> 
looking to add any new features to it. If you have an idea for a new 
feature in Moose, you are invited instead to create a MooseX:: module
of it first. At this stage, no new features will even be considered for 
addition into the core without first being vetted as a MooseX:: module.

But worry not, 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.

=head1 TESTS, TESTS, TESTS

If you write I<any> code in Moose or Class::MOP, you B<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.

=head1 BACKWARDS COMPATABILITY

Change is inevitable and Moose is not immune to this. We do our best 
to maintain backwards compatability, but we do not want the codebase 
to become overburdened by this. This is not to say that we will 
be frivolous with our changes, quite the opposite, it is more to say 
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 compatabile
you B<must> do I<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 B<must> be documented in 
L<Moose::Manual::Delta> and when possible should provide any useful 
tips or workarounds to help smooth the transition process.

=head1 AUTHOR

Stevan Little E<lt>stevan@iinteractive.comE<gt>

=head1 COPYRIGHT AND LICENSE

Copyright 2009 by Infinity Interactive, Inc.

L<http://www.iinteractive.com>

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

=cut