diff --git a/DEVELOPMENT.txt b/DEVELOPMENT.txt
index 69af3cd8..7d2874fb 100644
--- a/DEVELOPMENT.txt
+++ b/DEVELOPMENT.txt
@@ -6,10 +6,17 @@ Development process
 
  * Go to `http://github.com/stefanv/scikits.image
    <http://github.com/stefanv/scikits.image>`_  and follow the instructions on
-   making your own fork/branch.
- * Make changes to your branch, committing locally as you progress.
+   making your own fork.
+ * Create a new branch for the feature you want to work on.
+ * Commit locally as you progress.
  * Push your changes back to github.
- * Ping stefan to request a merge into the main development branch.
+ * Ping Stefan to request a merge into the main development branch (or simply
+   click on "Request Pull" in GitHub).
+
+You may also read this summary by Fernando Perez of the IPython project on how
+they manage to keep review overhead to a minimum:
+
+http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html
 
 .. note::
 
@@ -17,10 +24,6 @@ Development process
    as long as you are `aware of its dangers <http://tinyurl.com/lll385>`_
    (also see `LWN article <http://tinyurl.com/nqcbkj>`_).
 
-All of this may be intimidating if you've never used git before, so we'd
-happily accept plain old unified diffs (``git diff`` or ``diff -u a.txt
-b.txt``) as well.
-
 Guidelines
 ``````````
  * All code should have tests (see "Test coverage" below for more details).
@@ -29,9 +32,9 @@ Guidelines
    as NumPy and SciPy.
  * Follow the `Python PEPs <http://www.python.org/dev/peps/pep-0008/>`_
    where possible.
- * All major changes should be `posted for review
-   <http://codereview.appspot.com>`_ to the `mailing list
-   <http://groups.google.com/group/scikits-image>`_.
+ * No major changes should be committed without review.  Ask on the
+   `mailing list <http://groups.google.com/group/scikits-image>`_ if you get
+   no response to your pull request.
 
 Test coverage
 `````````````