From: Dave Rolsky Date: Mon, 3 Aug 2009 00:33:10 +0000 (-0500) Subject: lots of wording tweaks for approval workflow X-Git-Tag: 0.89~20 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=0b81ea16db46a9b713d9e25ddef6c51344fb551f;p=gitmo%2FMoose.git lots of wording tweaks for approval workflow --- diff --git a/lib/Moose/Manual/Contributing.pod b/lib/Moose/Manual/Contributing.pod index 5367262..ca8d6d5 100644 --- a/lib/Moose/Manual/Contributing.pod +++ b/lib/Moose/Manual/Contributing.pod @@ -148,11 +148,11 @@ All large changes should be documented in L. =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 responsibility to follow this process and advocate for your branch. @@ -164,51 +164,52 @@ which have been approved. =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 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 section for -more information on that. If your feature needs core support, create a topic/ -branch using the L and start hacking away. +TODO tests are basically feature requests, see our L section +for more information on that. If your feature needs core support, create a +topic/ branch using the L 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 cabal member. +Anything that creates a new user-visible feature needs to be approved by +B cabal member. -Make sure you have reviewed L 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 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 cabal member. +New features for Moose internals are less restrictive then user facing +features, but still require approval by B 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 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 for +Moose. If your changes break back-compat, you must be ready to discuss and +defend your change. =back