svn commit: r680924 - /incubator/buildr/trunk/doc/pages/contributing.textile

[as...@apache.org]

Author: assaf
Date: Tue Jul 29 23:51:19 2008
New Revision: 680924

URL: http://svn.apache.org/viewvc?rev=680924&view=rev
Log:
Added four rules for submitting a patch that will get accepted quickly.

Modified:
    incubator/buildr/trunk/doc/pages/contributing.textile

Modified: incubator/buildr/trunk/doc/pages/contributing.textile
URL: http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/contributing.textile?rev=680924&r1=680923&r2=680924&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/contributing.textile (original)
+++ incubator/buildr/trunk/doc/pages/contributing.textile Tue Jul 29 23:51:19 2008
@@ -59,6 +59,29 @@
 Apache gets the right to use your contribution, and the JIRA upload form
 includes a simple contribution agreement.  Lawyer not included.
 
+h4.  The Perfect Patch
+
+If you want to get your patch accepted quickly:
+
+#  Provide a good summary of the bug/fix.  We use that to decide which issue
+   we can do quickly, and also copy and paste it into the changelog.
+#  Provide short explanation of what failed, under what conditions, why, and
+   what else could be affected by the change (when relevant).  The helps us
+   understand the problem and move on to the next step.
+#  Provide a patch with relevant specs, or a fix to incomplete/broken specs.
+   First thing we have to do is replicate the problem, before applying the
+   change, and then make sure the change fixes that problem.  And we need to
+   have those specs in there, they make sure we don't accidentally break it
+   again in the future.
+#  Provide a patch with the fix/change itself.  Keep it separate from the
+   specs, so it's easy to apply them individually.
+
+If you don't know how to fix it, but can at least write a spec for the correct
+behavior (which, obviously would fail), do just that.  A spec is preferred to
+a fix.
+
+h4.  Working on a new feature?
+
 If you want to work on a cool new feature, but not quite ready to submit a
 patch, there's still a way you can get the Buildr community involved.  We're
 experimenting with using Git for that.  You can use Git to maintain a fork
@@ -67,7 +90,8 @@
 
 That way you can get other people involved, checking out the code, and
 eventually merge it back with the main branch.  Check out the
-"Git section":#Git below.
+"Git section":#Git below and the post "Git forking for fun and
+profit":http://blog.labnotes.org/2008/04/30/git-forking-for-fun-and-profit/.
 
 
 h2.  Living on the edge