lib/Moose/Manual/Contributing.pod

   1 =pod
   2
   3 =head1 NAME
   4
   5 Moose::Manual::Contributing - How to get involved in Moose
   6
   7 =head1 GETTING INVOLVED
   8
   9 Moose is a pretty open project and we are always willing to accept
  10 bug fixes, more tests and doc patches. Doing these things is as
  11 simple as cloning a copy of the git repository and hacking away. All
  12 we ask is that for any non-trivial code patches, you check with one
  13 of the core developers before applying said patch.
  14
  15 =head1 NEW FEATURES
  16
  17 Moose already has a fairly large feature set and we are currently B<not>
  18 looking to add any new features to it. If you have an idea for a new
  19 feature in Moose, you are invited instead to create a MooseX:: module
  20 of it first. At this stage, no new features will even be considered for
  21 addition into the core without first being vetted as a MooseX:: module.
  22
  23 But worry not, Moose was built from the ground up with the idea of being
  24 highly extensible and quite often the feature requests we see can be
  25 implemented through a couple of small and well placed extensions. Try it,
  26 it is much easier then you might think.
  27
  28 =head1 TESTS, TESTS, TESTS
  29
  30 If you write I<any> code in Moose or Class::MOP, you B<must> add tests
  31 for that code. If you do not write tests then we cannot guarantee your
  32 change will not be removed or altered at a later date.
  33
  34 If your code change/addition is deep within the bowels of Moose/Class::MOP
  35 and your test exercises this feature in a non-obvious way, please add some
  36 comments either near the code in question or in the test so that others
  37 know.
  38
  39 =head1 BACKWARDS COMPATABILITY
  40
  41 Change is inevitable and Moose is not immune to this. We do our best
  42 to maintain backwards compatability, but we do not want the codebase
  43 to become overburdened by this. This is not to say that we will
  44 be frivolous with our changes, quite the opposite, it is more to say
  45 that we are not afraid of change and will do our best to keep it as
  46 painless as possible for the end user.
  47
  48 The rule is that if you do something that is not backwards compatabile
  49 you B<must> do I<at least> one deprecation cycle (more if it is larger
  50 change). For really larger or radical changes dev releases may be needed
  51 as well (the core developers will decide on this on a case-per-case
  52 basis).
  53
  54 The preference with regard to deprecation is to warn loudly and often
  55 so that users will have time to fix their usages.
  56
  57 All backwards incompatible changes B<must> be documented in
  58 L<Moose::Manual::Delta> and when possible should provide any useful
  59 tips or workarounds to help smooth the transition process.
  60
  61 =head1 AUTHOR
  62
  63 Stevan Little E<lt>stevan@iinteractive.comE<gt>
  64
  65 =head1 COPYRIGHT AND LICENSE
  66
  67 Copyright 2009 by Infinity Interactive, Inc.
  68
  69 L<http://www.iinteractive.com>
  70
  71 This library is free software; you can redistribute it and/or modify
  72 it under the same terms as Perl itself.
  73
  74 =cut