Typographic fixes around double quotes.

1 files changed, 39 insertions, 39 deletions

diff --git a/wiki/dev/trackers-from-first-principles.md b/wiki/dev/trackers-from-first-principles.md
index cd4148f..d7c7a4c 100644
--- a/wiki/dev/trackers-from-first-principles.md
+++ b/wiki/dev/trackers-from-first-principles.md
@@ -10,11 +10,11 @@ Why do we track tasks?
     * Otherwise we'd just remember it in our heads.
     * Wishlist tasks are not a bad thing!
 
-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
+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.
+* Therefore, “steps to reproduce” should not be a required datum.
 
 Bugs are an _important_ kind of task.
 
@@ -59,11 +59,11 @@ team-specific.
 There may be other people _involved_ in a task that are not _responsible_ for
 a task, in a number of roles. Just because I developed the code for a feature
 does not mean I am necessarily responsible for the feature any more, but it
-might be useful to have a "developed by" list for the feature's task.
+might be useful to have a “developed by” list for the feature's task.
 
 Ways of identifying people:
 
-* Natural-language names ("Gianna Grady")
+* Natural-language names (“Gianna Grady”)
 * Email addresses
 * Login names
 * Distinguished names in some directory
@@ -74,7 +74,7 @@ communicate it, but do not normally define it.
 
 ## Workflow
 
-"Workflow" describes both the implications of the states a task can be in and
+“Workflow” describes both the implications of the states a task can be in and
 the implications of the transitions between states. Most task trackers are, at
 their core, workflow engines of varying sophistication.
 
@@ -93,10 +93,10 @@ work it describes.
 
 Elemental states:
 
-* "Open": in this state, the task has not yet been completed. Work may or may
+* “Open”: in this state, the task has not yet been completed. Work may or may
   not be ongoing.
-* "Completed": in this state, all work on a task has been completed.
-* "Abandoned": in this state, no further work on a task will be performed, but
+* “Completed”: in this state, all work on a task has been completed.
+* “Abandoned”: in this state, no further work on a task will be performed, but
   the task has not been completed.
 
 Most real-world workflows introduce some intermediate states that tie into
@@ -104,29 +104,29 @@ process-related handoffs.
 
 For software, I see these divisions, in various combinations, frequently:
 
-* "Open":
-    * "Unverified": further work needs to be done to decide whether the task
+* “Open”:
+    * “Unverified”: further work needs to be done to decide whether the task
       should be completed.
-    * "In Development": someone is working on the code and asset changes
+    * “In Development”: someone is working on the code and asset changes
       necessary to complete the task. This occasionally subsumes preliminary
       work, too.
-    * "In Testing": code and asset changes are ostensibly complete,
+    * “In Testing”: code and asset changes are ostensibly complete,
       but need testing to validate that the task has been completed
       satisfactorially.
-* "Completed":
-    * "Development Completed": work (and possibly testing) has been completed
+* “Completed”:
+    * “Development Completed”: work (and possibly testing) has been completed
       but the task's results are not yet available to external users.
-    * "Released": work has been completed, and external users can see and use
+    * “Released”: work has been completed, and external users can see and use
       the results.
-* "Abandoned":
-    * "Cannot Reproduce": common in bug/defect tasks, to indicate that the
+* “Abandoned”:
+    * “Cannot Reproduce”: common in bug/defect tasks, to indicate that the
       task doesn't contain enough information to render the bug fixable.
-    * "Won't Complete": the task is well-understood and theoretically
+    * “Won't Complete”: the task is well-understood and theoretically
       completable, but will not be completed.
-    * "Duplicate": the task is identical to, or closely related to, some other
+    * “Duplicate”: the task is identical to, or closely related to, some other
       task, such that completing either would be equivalent to completing
       both.
-    * "Invalid": the task isn't relevant, is incompletely described, doesn't
+    * “Invalid”: the task isn't relevant, is incompletely described, doesn't
       make sense, or is otherwise not appropriate work for the team using the
       tracker.
 
@@ -135,14 +135,14 @@ None of these are universal.
 Transitions show how a task moves from state to state.
 
 * Driven by external factors (dev work leads to tasks being marked completed)
-    * Explicit transitions: "mark this task as completed"
-    * Implicit transitions: "This commit also completes these tasks"
+    * Explicit transitions: “mark this task as completed”
+    * Implicit transitions: “This commit also completes these tasks”
 * Drive external factors (tasks marked completed are emailed to testers)
 
 States implicitly describe a _belief_ or a _desire_ about the future of the
 task, which is a human artifact and may be wrong or overly hopeful. Tasks can
-transition to "Completed" or "Abandoned" states when the work hasn't actually
-been completed or abandoned, or from "Completed" or "Abandoned" to an "Open"
+transition to “Completed” or “Abandoned” states when the work hasn't actually
+been completed or abandoned, or from “Completed” or “Abandoned” to an “Open”
 state to note that the work isn't as done as we thought it was. _This is a
 feature_ and trackers that assume every transition is definitely true and
 final encourage ugly workarounds like duplicating tickets to reopen them.
@@ -150,7 +150,7 @@ final encourage ugly workarounds like duplicating tickets to reopen them.
 ## Speciation
 
 I mentioned above that bugs are a kind of task. The ways in which bugs are
-"different" is interesting:
+“different” is interesting:
 
 * Good bugs have a well-defined reproduction case - steps you can follow to
   demonstrate and test them.
@@ -165,11 +165,11 @@ necessary.
 Supporting structure helps if it leads to more interesting or efficient ways
 of using tasks to drive and understand work.
 
-Bugs are not the only "special" kind of task:
+Bugs are not the only “special” kind of task:
 
-* "Feature" tasks show up frequently, and speciate on having room for
+* “Feature” tasks show up frequently, and speciate on having room for
   describing specs and scope.
-* "Support ticket" tasks show up in a few trackers, and speciate dramatically
+* “Support ticket” tasks show up in a few trackers, and speciate dramatically
   as they tend to be tasks describing the work of a single incident rather
   than tasks describing the work on some shared aspect, so they tend to pick
   up fields for relating tickets to the involved parties. (Arguably, incident
@@ -183,20 +183,20 @@ repro is a good example; every task whose goal is to fix a defect should
 include a clear understanding of the defect, both to allow it to be fixed and
 to allow it to be tested. Adding specialized data for bugs supports that by
 encouraging clearer, more structured descriptions of the defect (with implicit
-"fix this" as the task).
+“fix this” as the task).
 
 ## Implementation notes
 
-If we reduce task tracking to "record changes to fields and record discussion
-comments, on a per task basis", we can describe the current state of a ticket
-using the "most recent" values of each field and the aggregate of all recorded
+If we reduce task tracking to “record changes to fields and record discussion
+comments, on a per task basis,” we can describe the current state of a ticket
+using the “most recent” values of each field and the aggregate of all recorded
 comments. This can be done ~2 ways:
 
-1. "Centralized" tracking, where each task has a single, total order of
+1. “Centralized” tracking, where each task has a single, total order of
     changes. Changes are mediated through a centralized service.
-2. "Decentralized" tracking, where each task has only a partial order over the
+2. “Decentralized” tracking, where each task has only a partial order over the
     history of changes. Changes are mediated by sharing sets of changes, and by
-    appending "reconciliation" changes to resolve cases where two incomparable
+    appending “reconciliation” changes to resolve cases where two incomparable
     changes modify the same field/s. The most obvious partial order is a
     digraph.
 
@@ -204,16 +204,16 @@ Centralized tracking is a well-solved problem. Decentralized tracking so far
 seems to rely heavily on DSCM tools (Git, Mercurial, Fossil) for resolving
 conflicts.
 
-The "work offline" aspect of a distributed tracker is less interesting in as
+The “work offline” aspect of a distributed tracker is less interesting in as
 much as task tracking is a communications tool. Certain kinds of changes
 should be published and communicated as early as possible so as to avoid
 misunderstandings or duplicated work.
 
 Being able to separate the mechanism of how changes to tasks are recorded from
-the policy of which library of tasks is "canonical" is potentially useful as
+the policy of which library of tasks is “canonical” is potentially useful as
 an editorial tool and for progressive publication to wider audiences as work
 progresses.
 
 Issue tracking is considerably more amenable to append-only implementations
 than SCM is, even if you dislike history-editing SCM workflows. This suggests
-that Git is a poor choice of issue-tracking storage backends...
\ No newline at end of file
+that Git is a poor choice of issue-tracking storage backends...