Yesterday some people and I came up with the idea of “ShuffleFlow” for the name of the workflow project… It’s still in the works.
But, this time, I figured I’d write up what I want done by Christmas. Maybe a few use cases?
Use case #1: Software Development Company
Most software development teams use some mechanism to track bugs. However, in my experience the bug tracking system lends no intuition as to how bugs are fixed. For example, at Click Security we used FogBugz (there goes that NDA). FogBugz is a well thought-out system, don’t get me wrong: it allows for customization of pretty much everything, and it can link to mercurial to make code reviews easier. But at the end of the day, when you create a bug you’re faced with a myriad of options: What priority do you want the bug to be? Which sprint does the bug belong to? Who is the bug assigned to? What state is the bug in?
The last one always bugged me (no pun intended). The states were, if I remember correctly, “new”, “vetted”, “assigned”, “in progress”, “resolved”, and “closed”. I could never remember what state the bug was supposed to be in - If I just worked on it, and fixed the problem at hand, is it “resolved” or “closed”? If I was creating a new bug, as a sub-part to a bug I owned, was it “new”? Or was it “assigned”? Then, once I finally finished a bug, I had to create a code review request. That wasn’t even a state. Nor was it mentioned anywhere.
Shuffle (as it is currently being called) will need to make the bug tracking system obviously easy. The local technical manager first creates a workflow for bugs. The first item may be “new bug”. That item has a description that may say “These bugs are queued to be vetted and assigned.” That workitem leads to another one that’s called “in progress”, which in turn leads to the “fixed” workitem, which according to the description are “bugs that are to be reviewed by QA.” Fixed bugs have two fates: QA can approve them, and they can move to “code review”, or QA can disapprove of them, and they can be moved back to “in progress.”
Here’s a brief summary of the features required to make this user happy:
- Multiple permission levels. The manager is allowed to edit the workflow, but the developers and other grunts may only edit the tasks within the workflow. Upper management, being the people they are, is only allowed read-access to the workflow lest they screw something up.
- Multiple workitem targets. A single workitem may have multiple subsequent workitems. The user interface must let the user easily manage multiple sources and targets. Furthermore, the user interface must allow the grunts to decide whether or not the task they’re advancing should move to “code review” or to “in progress”.
- Task and workitem descriptions. The manager must be able to give workitems descriptions, such as saying that “in progress” is where “Bugs are being worked on by the programmer.” Tasks must also have descriptions, so that grunts can say that “this bug is reproducible by doing
.“ These descriptions must be able to express hyperlinks, either with HTML code or wiki style ([[http://www.google.com/]]). - Task comments. Task descriptions should have a mechanism to comment on a task, like in blogging platforms, BugZilla, and FogBugz.
- Appearance. It should look halfway decent. i.e. not vomit-inducing.
- User management. Somebody must be able to create users, remove users, and change a user’s permissions.
Actually, that’s my only use case at this time. Stay tuned for further use cases in hospitals and university admissions!
There is now a release versioning scheme in the works. Releases will be named after the NATO phonetic alphabet - the first one will be Alfa, the second Bravo, then Charlie, and so on. Then there will be a sub-version tacked onto that: alpha, beta, or release. Alpha releases will be technical-feature-complete. Beta releases are usable-feature-complete and major-bug-complete, and releases are both bug-complete and polish-complete.
I intend to become feature complete for user case #1 by Christmas. That gives me 44 days before the Alfa alpha release.