From: Dave Rolsky Date: Fri, 19 Nov 2010 03:04:05 +0000 (-0600) Subject: Some small tweaks, and section on writing docs X-Git-Tag: 1.9900~26 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=daae2c87757698f5e76ed0d4e50653924ca43e25;p=gitmo%2FMoose.git Some small tweaks, and section on writing docs --- diff --git a/lib/Moose/Manual/Contributing.pod b/lib/Moose/Manual/Contributing.pod index c161ae4..90a00ec 100644 --- a/lib/Moose/Manual/Contributing.pod +++ b/lib/Moose/Manual/Contributing.pod @@ -121,10 +121,10 @@ moved here, to keep the main areas clean. =back -Larger, more long term branches can also be created in the root namespace (i.e. -at the same level as master and stable). This is more appropriate if multiple +Larger, longer term branches can also be created in the root namespace (i.e. +at the same level as master and stable). This may be appropriate if multiple people are intending to work on the branch. These branches should not be -rebased. +rebased without checking with other developers first. =head1 STANDARD WORKFLOW @@ -216,8 +216,9 @@ 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. Backwards incompatbible changes should not be merged to master if there +are strong objections for any cabal 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 @@ -329,8 +330,8 @@ C is a valid ref). Merged branches should be deleted. -Failed branches may be kept, but should be to C to differentiate them -from in-progress topic branches. +Failed branches may be kept, but should be moved to C to differentiate +them from in-progress topic branches. Branches that have not been worked on for a long time will be moved to C periodically, but feel free to move the branch back to C @@ -352,6 +353,16 @@ We also greatly appreciate documentation to go with your changes, and an entry in the Changes file. Make sure to give yourself credit! Major changes or new user-facing features should also be documented in L. +=head1 DOCS, DOCS, DOCS + +Any user-facing changes must be accompanied by documentation. If you're not +comfortable writing docs yourself, you might be able to convince another Moose +dev to help you. + +Our goal is to make sure that all features are documented. Undocumented +features are not considered part of the API when it comes to determining +whether a change is backwards compatible. + =head1 BACKWARDS COMPATIBILITY Change is inevitable, and Moose is not immune to this. We do our best