Notes towards bug tracking.

1 files changed, 27 insertions, 0 deletions

diff --git a/wiki/dev/trackers-from-first-principles.md b/wiki/dev/trackers-from-first-principles.md
new file mode 100644
index 0000000..d69ca37
--- /dev/null
+++ b/wiki/dev/trackers-from-first-principles.md
@@ -0,0 +1,27 @@
+# Bugs, Tasks, and Tickets from First Principles
+
+Why do we track tasks?
+
+* To communicate about what should, will, has, and will not be done.
+    * Consequently, to either build consensus on what to do next or to dictate
+      it.
+* To measure and communicate progress.
+* To preserve information.
+    * Otherwise we'd just remember it in our heads.
+
+Bugs/defects are a kind of task but not the only kind. Most teams have a "bug
+tracker" that contains a lot more than bugs. Let's not let bugs dictate the
+system.
+
+* Therefore, "steps to reproduce" should not be a required datum.
+
+Bugs are an _important_ kind of task.
+
+Tasks can be related to software development artifacts: commits, versions,
+builds, releases.
+
+* A task may only be complete as of certain commits/releases/builds.
+* A task may only be valid after (or before) certain commits/releases/builds.
+
+Communication loosely implies publishing. Tracking doesn't, but may rely on
+the publishing of other facts.