Docs: Updated dev docs

DEVELOPER

@@ -105,9 +105,6 @@ Deprecated Code
   This is code that is going to be phased out soon, and therefore is not worth
   fixing or documenting. Don't waste your time.
 
-  - Priorities in core. This will be migrated to become a UDA as soon as we
-    have the right support in place for custom sorting.
-
   - Nag feature.
 
   - Attribute modifiers.
@@ -119,9 +116,6 @@ New Code Needs
     or template script serving as a starting-point for anyone who needed this
     format.
   - Need new export_xxx.* scripts - the more the better. Any language.
-  - The JSON.{h,cpp} code is fast and efficient up to a point, but has a non-
-    linear performance curve, implying a slowdown due to fragmentation, but who
-    know? Find it, fix it.
   - Need an external script that can locate and correct duplicate UUIDs in the
     data file, as found by 'task diag'. This should check to see if there is
     a suitable UUID generator installed. This should also be careful to
@@ -142,20 +136,20 @@ Unit Tests Needed
      For example, dependencies.t runs through a long list of commands that test
      dependencies, but do so by using 'add', 'modify', 'done' and 'delete'.
   2. Regression tests that ensure certain bugs are fixed and stay fixed. These
-     tests are named bug.NNN.t where NNN refers to the Redmine issue number.
+     tests are named bug.NNN.t where NNN refers to the bug number. While it is
-     While it is not worth creating tests for small fixes like typos, it is for
+     not worth creating tests for small fixes like typos, it is for changes to
-     changes to the logic.
+     the logic.
   3. Small feature tests. When small features are added, we would like small,
-     low-level feature tests named feature.NNN.t, where NNN is the Redmine
+     low-level feature tests named feature.t, with a descriptive name and
-     issue number.
+     focused tests.
   4. Code tests. These are tests written in C++ that exercise C++ objects, or
      function calls. These are the lowest level tests. It is important that
      these kind of tests be extensive and thorough, because the software depends
      on this code the most.
 
-  The tests are mainly written in Perl, and all use TAP. We want them all to be
+  The tests are mainly written in Perl, and all use TAP. We are replacing these
-  eventually replaced by Python, so we are now only accepting new tests that use
+  with Python equivalents, so we are now only accepting new tests that use the
-  the Python-based approach you can see in some of the existing tests.
+  Python-test framework.
 
   Tests needed:
 
@@ -173,7 +167,7 @@ Unit Tests Needed
     'needsTest' label.
 
   Note that running the unit tests currently requires the Perl JSON module to
-  be installed.
+  be installed. This will change soon.
 
   Note that all new unit tests should follow the test/template.t standard.
 
@@ -188,11 +182,11 @@ Work in Progress
 Current Codebase Condition
 
   'master' branch:
-    - 2.4.3 Current release, locked.
+    - 2.4.4 Current release, locked.
 
-  '2.4.4' branch:
+  '2.4.5' branch:
     - Current development branch no plans yet.
 
 ---
 
-2015-04-21 Updated for 2.4.4
+2015-07-11 Updated for 2.4.5

EXPOSITION

@@ -151,16 +151,16 @@ Test Suite
   A strong and diverse test suite is critical to the successful release of any
   software. With the complex command set and its myriad permutations, a test
   suite is the only way to ensure quality levels, and guarantee that big changes
-  are sound.
+  are robust.
 
   It is intended that the test suite continues growing, mostly adding more
   regression and feature tests. The test are mostly written in Perl, and utilize
   the Test::More module to generate TAP output. This is changing though, and the
-  suite is slowly migrating to Python. Some tests are written in C++ and all
+  suite is migrating to Python. Some tests are written in C++ and all tests
-  tets generate TAP output.
+  generate TAP output.
 
-  There are currently about 8,000 unit tests, that take a minute or two to run
+  There are currently about 8,000 unit tests, that take only a few seconds to
-  in total.
+  run on a multi-core machine.
 
   Taskwarrior uses flod software to automate continuous integration across many
   platforms. Code changes are automatically detected, propagated, built and
@@ -184,7 +184,7 @@ Debugging
     - TDB2 layer and I/O information.
 
   Additionally, there are other settings (see 'man taskrc' for full details) that
-  may also be helpful: 'rc.hooks=on|off', 'rc.debug.parser=0|1|2',
+  may also be helpful: 'rc.hooks=on|off', 'rc.debug.parser=0|1|2|3',
   'rc.debug.hooks=0|1|2', 'rc.debug.tls=0|1|2|3...'.
 
 
@@ -193,7 +193,8 @@ Patches
   Jira issue, or send them to support@taskwarrior.org. A good patch:
 
     - Maintains the MIT license, and does not contain code lifted from other
-      sources.
+      sources. You will have written 100% of the code in the patch, otherwise
+      we cannot maintain the license.
     - Precisely addresses one issue only.
     - Doesn't break unit tests.
     - Doesn't introduce dependencies.
@@ -202,9 +203,10 @@ Patches
     - Conforms to the prevailing coding standards - in other words, it should
       fit right in with the existing code.
 
-  A patch may be rejected for not following the above guidelines, and more.
+  A patch may be rejected for violating any of the above rules, and more.
   Bad patches may be accepted and modified depending on work load and mood. It
   is possible that a patch may be rejected because it conflicts in some way with
-  plans or upcoming changes.
+  plans or upcoming changes. Check with us first, before sinking time and effort
+  into a patch.
 
 ---