initial commitHEADmaster

1 files changed, 31 insertions, 0 deletions

diff --git a/sifterapp/ideal-sifter-workflow.txt b/sifterapp/ideal-sifter-workflow.txt
new file mode 100644
index 0000000..4fdc269
--- /dev/null
+++ b/sifterapp/ideal-sifter-workflow.txt
@@ -0,0 +1,31 @@
+Streamlining Bug & Issue Tracking Workflow
+
+The quest to have a perfect workflow leads to ambiguous and redundant statuses. Can an issue be resolved and not in progress at the same time? i.e. The original tester is no longer around, so who retests it. Can it be pending/resolved at the same time? If it's moved to pending, it now becomes difficult to remember what state it was at previously.
+
+
+This would essentially help people visualize the implicit nature of frequently requested statuses that we don’t explicitly plan on adding.
+
+
+How do we suggest working with issues in Sifter? 
+
+This would be a diagram illustrating both the explicit and virtual states that Sifter helps manage.
+
+
+> I’d create a diagram to illustrate it kind of like this with guidance on how to create/bookmark the corresponding filters for convenience.
+
+
+* New -> Open w/o milestone/assignee
+* Accepted -> Open & Assigned to a milestone.
+* Pending/On Hold -> Open & No milestone, no assignee
+* In Progress -> Open & Assigned to a user.
+* Open
+* Resolved
+* Closed
+* Rejected -> Closed w/ explanation.
+* Working as Designed -> Closed w/ explanation.
+* Duplicate -> Closed w/ explanation.
+
+The underlying challenge is that we often want machines to explicitly handle every potential scenario. In some cases, this is useful, but in others, we're pushing work off to a machine when humans are infinitely better at handling it. Trying to eliminate any ambiguity requires giving the system a lot of additional information.
+ 
+ 
+These "meta-statuses" shouldn't be treated the same as actual statuses. They add additional layers of meaning to a status, but they shouldn't live in parallel with the primary statuses.