Update and rename DEVELOPER to DEVELOPER.md

Rough markdownification, no content changes

DEVELOPER.md

@@ -1,13 +1,13 @@
-How to Build Taskwarrior
+# How to Build Taskwarrior
 
-  Satisfy the Requirements:
+## Satisfy the Requirements:
-    - gcc 4.9 or later, clang 3.4 or later, or a compiler with full C++11
+ * gcc 4.9 or later, clang 3.4 or later, or a compiler with full C++11 support.
-      support.
+ * libuuid (if not on macOS)
-    - libuuid (if not on macOS)
+ * gnutls (optional)
-    - gnutls (optional)
+ * python 2.7 or 3 (optional, for running the test suite)
-    - python 2.7 or 3 (optional, for running the test suite)
 
-  Obtain and build code:
+## Obtain and build code:
+```
     $ git clone --recursive https://git.tasktools.org/TM/task.git task.git
     $ cd task.git
     $ git checkout 2.5.2                 # Latest dev branch
@@ -16,12 +16,15 @@ How to Build Taskwarrior
     $ cmake -DCMAKE_BUILD_TYPE=debug .   # debug or release. Default: neither
     $ make VERBOSE=1 -j4                 # Shows details, builds using 4 jobs
                                          # Alternately 'export MAKEFLAGS=-j 4'
+```
+## Running Test Suite:
 
-  Running Test Suite:
+```
     $ cd tests
     $ make VERBOSE=1                     # Shows details
     $ ./run_all                          # Runs all tests silently > all.log
     $ ./problems                         # Enumerate test failures in all.log
+```
 
   Note that any development should be performed using a git clone, and the
   current development branch. The source tarballs do not reflect HEAD, and do
@@ -32,46 +35,46 @@ How to Build Taskwarrior
   against the tarball source, or master.
 
 
-General Statement
+# General Statement
   This file is intended to convey the current efforts, priorities and needs of
   the code base. It is for anyone looking for a way to start contributing.
   Here are many ways to contribute that may not be obvious:
 
-  - Use Taskwarrior, become familiar with it, and make suggestions. There are
+  * Use Taskwarrior, become familiar with it, and make suggestions. There are
     always ongoing discussions about new features and changes to existing
     features.
 
-  - Join us in the #taskwarrior IRC channel on freenode.net. Many great ideas,
+  * Join us in the #taskwarrior IRC channel on freenode.net. Many great ideas,
     suggestions, testing and discussions have taken place there. It is also
     the quickest way to get help, or confirm a bug.
 
-  - Review documentation: there are man pages, online articles, tutorials and
+  * Review documentation: there are man pages, online articles, tutorials and
     so on, and these may contain errors, or they may not convey ideas in the
     best way. Perhaps you can help improve it. Contact us - documentation is
     a separate effort from the code base, and includes all web sites, and all
     are available as git repositories.
 
-  - Take a look at the bug database, and help triage the bug list. This is a
+  * Take a look at the bug database, and help triage the bug list. This is a
     review process that involves confirming bugs, providing additional data,
     information or analysis. Bug triage is very useful and much needed. You
     could check to see that an old bug is still relevant - sometimes they are
     not.
 
-  - Review the source code, and point out inefficiencies, problems, unreadable
+  * Review the source code, and point out inefficiencies, problems, unreadable
     functions, bugs and assumptions.
 
-  - Fix a bug. For this you'll need C++ and Git skills. We welcome all bug
+  * Fix a bug. For this you'll need C++ and Git skills. We welcome all bug
     fixes, provided the work is done well and doesn't create other problems or
     introduce new dependencies. We recommend talking to us before starting.
     Seriously.
 
-  - Add unit tests. Unit tests are possibly the most useful contributions of
+  * Add unit tests. Unit tests are possibly the most useful contributions of
     all, because they not only improve the quality of the code, but prevent
     future regressions, therefore maintaining quality of subsequent releases.
     Plus, broken tests are a great motivator for us to fix the causal defect.
     You'll need Python skills.
 
-  - Add a feature. Well, let's be very clear about this: adding a feature is
+  * Add a feature. Well, let's be very clear about this: adding a feature is
     not usually well-received, and if you add a feature and send a patch, it
     will most likely be rejected. The reason for this is that there are many
     efforts under way, in various code branches. There is a very good chance
@@ -82,57 +85,57 @@ General Statement
     already rejected such a feature for some very good reasons. So please
     check first, so we don't duplicate effort or waste anyone's time.
 
-  - Spread the word. Help others become more effective at managing tasks.
+  * Spread the word. Help others become more effective at managing tasks.
 
-  - Encouragement. Tell us what works for you, and what doesn't. Tell us about
+  * Encouragement. Tell us what works for you, and what doesn't. Tell us about
     your methodology for managing tasks. It's all useful information.
 
-  - Request a feature. This not only tells us that you think something is
+  * Request a feature. This not only tells us that you think something is
     missing from the software, but gives us insights into how you use it.
     Plus, you might get your feature implemented.
 
-Unit Tests Needed
+# Unit Tests Needed
   There are always more unit tests needed. More specifically, better unit tests
   are always needed. The convention is that there are four types of unit test:
 
   1. High level tests that exercise large features, or combinations of commands.
      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
+  1. Regression tests that ensure certain bugs are fixed and stay fixed. These
      tests are named tw-NNNN.t where NNNN refers to the bug number. While it is
      not worth creating tests for small fixes like typos, it is for logic
      changes.
-  3. Small feature tests. When small features are added, we would like small,
+  1. Small feature tests. When small features are added, we would like small,
      low-level feature tests named feature.t, with a descriptive name and
      focused tests.
-  4. Code tests. These are tests written in C++ that exercise C++ objects, or
+  1. 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 written in Python, Bash and C++, and all use TAP.
 
-  Tests needed:
+## Tests needed
 
-  - Take a look at the bug database (https://bug.tasktools.org) and notice that
+  * Take a look at the bug database (https://bug.tasktools.org) and notice that
     many issues, open and closed, have the "needsTest" label. These are things
     that we would like to see in the test suite, as regression tests.
 
   All new unit tests should follow the test/template.t standard.
 
-Patches
+# Patches
   Patches are encouraged and welcomed. Either attach them to the appropriate
   Jira issue, or send them to support@taskwarrior.org. A good patch:
 
-    - Maintains the MIT license, and does not contain code lifted from other
+    * Maintains the MIT license, and does not contain code lifted from other
       sources. You will have written 100% of the code in the patch, otherwise
       we cannot maintain the license.
-    - Precisely addresses one issue only.
+    * Precisely addresses one issue only.
-    - Doesn't break unit tests.
+    * Doesn't break unit tests.
-    - Doesn't introduce dependencies.
+    * Doesn't introduce dependencies.
-    - Is accompanied by unit tests, where appropriate.
+    * Is accompanied by unit tests, where appropriate.
-    - Is accompanied by documentation changes, where appropriate.
+    * Is accompanied by documentation changes, where appropriate.
-    - Conforms to the prevailing coding standards - in other words, it should
+    * Conforms to the prevailing coding standards - in other words, it should
       fit in with the existing code.
 
   A patch may be rejected for violating any of the above rules, and more.
@@ -141,13 +144,13 @@ Patches
   plans or upcoming changes. Check with us first, before sinking time and effort
   into a patch.
 
-Current Code Base Condition
+# Current Code Base Condition
 
-  'master' branch:
+**'master' branch**:
-    - 2.5.1 Current release, locked.
+ * 2.5.1 Current release, locked.
 
-  '2.6.0' branch:
+ **'2.6.0' branch**:
-    - Current development branch no plans yet.
+  * Current development branch no plans yet.
 
 ---