=head1 APPROVAL WORKFLOW
-Moose is an open project but it also an increasingly important one, whose stability
-is depended on by many other modules. Therefore we need some basic set of
-criteria for accepting and approving branches into the core. What follows is the
-set of rough guidelines to be sure that all new code is properly vetted before it
-enters the core.
+Moose is an open project but it is also an increasingly important one. Many
+modules depend on Moose being stable. Therefore, we have a basic set of
+criteria for reviewing and merging branches. What follows is a set of rough
+guidelines that ensures all new code is properly vetted before it is merged to
+the master branch.
It should be noted that if you want your specific branch to be approved, it is
B<your> responsibility to follow this process and advocate for your branch.
=item Small bug fixes, doc patches and additional passing tests.
-These items don't really require approval beyond one of the core contributors just
-doing a simple review.
+These items don't really require approval beyond one of the core contributors
+just doing a simple review.
=item Larger bug fixes, doc additions and TODO or failing tests.
Larger bug fixes should be reviewed by at least one cabal member and should be
-tested using the smolder script to be sure no new issues were introduced.
+tested using the F<cpan-stable-smolder> script in the moose-dev-utils
+repository.
New documentation is always welcome, but should also be reviewed by a cabal
member for accuracy.
-TODO tests are basically feature requests, see our L</NEW FEATURES> section for
-more information on that. If your feature needs core support, create a topic/
-branch using the L</STANDARD WORKFLOW> and start hacking away.
+TODO tests are basically feature requests, see our L</NEW FEATURES> section
+for more information on that. If your feature needs core support, create a
+topic/ branch using the L</STANDARD WORKFLOW> and start hacking away.
-Failing tests are basically bug reports, you should find a core contributor and/or
-cabal member to see if it is a real bug, then submit it and your test to the RT
-queue. Source control is not a bug reporting tool.
+Failing tests are basically bug reports. You should find a core contributor
+and/or cabal member to see if it is a real bug, then submit the bug and your
+test to the RT queue. Source control is not a bug reporting tool.
=item New user-facing features.
-Anything that creates a new feature that is visible to a user needs to be approved
-by B<more then one> cabal member.
+Anything that creates a new user-visible feature needs to be approved by
+B<more then one> cabal member.
-Make sure you have reviewed L</NEW FEATURES> to be sure that you are following the
-guidelines. Do not be suprised if a new feature is rejected if it has not been either
-first vetted as a MooseX module or you cannot prove it is impossible to implement
-outside of core.
+Make sure you have reviewed L</NEW FEATURES> to be sure that you are following
+the guidelines. Do not be surprised if a new feature is rejected for the core.
=item New internals features.
-New features for Moose internals are less restrictive then user facing features,
-but still require approval by B<at least one> cabal member.
+New features for Moose internals are less restrictive then user facing
+features, but still require approval by B<at least one> cabal member.
-Ideally you will have run a smolder script to be sure your not breaking any of the
-MooseX modules or causing any other unforseen havok. If you do this (rather then make
-us do it), it will only help to hasten your approval.
+Ideally you will have run the smolder script to be sure you are not breaking
+any MooseX module or causing any other unforeseen havoc. If you do this
+(rather then make us do it), it will only help to hasten your branch's
+approval.
=item Backwards incompatible changes.
-Anything that breaks backwards compatibility must be discussed by the cabal and
-agreed to by a majority of the members.
+Anything that breaks backwards compatibility must be discussed by the cabal
+and agreed to by a majority of the members.
-We have a policy for what we see as sane L</BACKWARDS COMPATIBILITY> for Moose. If
-your changes break back-compat, you must be ready to discuss and debate your change.
+We have a policy for what we see as sane L</BACKWARDS COMPATIBILITY> for
+Moose. If your changes break back-compat, you must be ready to discuss and
+defend your change.
=back
projects / gitmo/Moose.git / commitdiff