These people have worked with the Moose codebase for a while.
They've been responsible for large features or branches and can help review
-your changes and apply them to the master branch.
+your changes and apply them to the master branch using the basic
+L</APPROVAL WORKFLOW>.
They are also fairly well versed in Git, in order to merge the branches with
no mistakes (especially when the merge fails), and to provide advice to
git rebase --interactive # allowed
git push --force origin topic/my_feature # allowed
-Then go on IRC, ask for someone to review, and merge to master. If it merges
-cleanly and nobody has any objections, then it can be pushed to master.
+Then ask for a review/approval (see L</APPROVAL WORKFLOW>), and merge
+to master. If it merges cleanly and nobody has any objections, then it
+can be pushed to master.
If it doesn't merge as a fast forward, the author of the branch needs to run
All large changes should be documented in L<Moose::Manual::Delta>.
+=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.
+
+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.
+The preferred way is to send a request to the mailing list for review/approval,
+this allows us to better keep track of the branches awaiting approval and those
+which have been approved.
+
+=over 4
+
+=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.
+
+=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.
+
+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.
+
+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.
+
+=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.
+
+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.
+
+=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.
+
+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.
+
+=item Backwards incompatible changes.
+
+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.
+
+=back
+
=head1 RELEASE WORKFLOW
git checkout master
projects / gitmo/Moose.git / commitdiff