Done and confirmed

It’s difficult to manage people who are doing a lot of micro-tasks, like fixing bugs. Currently there’s only a “done” checkbox, but what’s needed is also a “confirmed done” checkbox. The way it would work is this:

1. A developer fixes a bug or finises small task, and clicks “done”.

2. Once a week I log on and filter by “done, but not confirmed” so I can see all the stuff that’s supposedly done but I haven’t verified yet.

3. For each item, I can either check “confirmed done” if I agree it looks good, or if I’m not satisfied, I can un-check “done” and bounce it back to the developer with a comment added about what’s wrong.

But without a way to check off things that are supposedly done, it’s hard to manage numerous tasks. Thanks for making a great product!

It’s in our roadmap to add features that would allow you move items through a simple process like this.

Using containers (projects or categories) to model workflow works pretty well also. Here is a blog post I wrote on that:
http://www.liquidplanner.com/blog/2008/03/06/bu…

Ah, that’s pretty sweet. I made two categories “Verified” and “Unverified” that let me mark whether I think things are done independantly of whether the task-owners think it’s done. But I guess I’m just preaching to the choire here.

I’m involved in software development and have struggled with this same issue. I need to review all tasks assigned to other developers and setting up corresponding review tasks that depend on the completion of the programming task or bug fix is tedious. It would be nice if programming tasks were treated more like trouble tickets such that more than one person would play a role, in sequence, for the same “ticket” taking it from initial definition, through development, testing, review, and finally completion. So I’m quite interested in this notion of having a simple process or mini workflow for individual tasks.

I did try using a sub-project for each “ticket” with tasks for the doing and reviewing, but that wasn’t an ideal solution as those task names still needed to be as lengthy as the sub-project name in order to make sense in other views, such as the category view. Which loses a lot of the benefits of using the sub-project as a template, especially as dependencies don’t get copied.

Here is what I really would like. I want to create one “ticket” that represents a programming item, such as fixing a bug. I want to estimate the amount of effort required by one or more individuals to resolve the issue in the ticket. In the most common, simple case, one programmer will write or fix the code, and another will review the code. The review cannot begin until the programming is done, and the “ticket” as a whole cannot be closed until it has been reviewed and deemed complete. The review might uncover the need for the original programmer to do additional work. If not, the entire ticket can be marked as done.

Is that the kind of simple process that you are targeting in your roadmap?

I forgot to mention what we have been doing so far. At the moment, I just create a task for the developer. When the developer is done, they create a task for me to review their work. I get email notified that I have review tasks and then I do the review, and either comment on the original task or mark it as done. The problem with this approach is that my schedule does not project the amount of time that I will need to spend on reviews.

This could be solved by creating review tasks at the same time as the original task, but then I have to create dependencies, make sure name changes get applied to both tasks, move both tasks in or out of the backlog together, etc.

I look forward to whatever you folks come up with as I’m sure you must have similar issues while managing the development of LP. :-)

Ultimately the idea is to build in mini-workflows for tasks; but that is a ways out. I can tell you how I’d approach it in LiquidPlanner right now, but this approach does use a feature that is coming in our August release.

The simplest solution is to just have your devs assign their tasks to you with a comment that says something to the effect of, “please review and return”.

Another approach is to set up containers that model the process. We do both those things on the LP team You might try finding the right place in the plan to drop in a high-priority container called “Task Reviews”. It might look something like this:

• Apollo Project, Patrick
  • Task Reviews, Patrick (on watch)
    • Time for reviews, Patrick
    • Task 4, Alex
    • Task 5, Charles
  • Task 1, Bob
  • Task 2, Alex
  • Task 3, Bob

When a review is needed, it gets dropped into “Task Reviews” and remains assigned to the original person, this is cool because you can still filter on that person and work in batch mode (eg. all of Alex’s tasks first). Of course this does not account for your time in the schedule forecast; it may be the case as a manager that you don’t even need to do this because you are never the critical path. If you do need to account for this time, you could add a task like I’ve shown, called “Time for reviews”. You can log progress to this task each time you process reviews which will give you a retrospective view via the Analysis tab of how much time you are spending on reviews. You can also estimate how much time you plan to spend on reviews on that same task (eg, 5-10 days over the course of the project). Another approach to accounting for your time in the schedule is to reduce your overall availability; if you spend a day a week on this consistently then drop down to 4 days a week availability.

The new feature coming is that you’ll be able to set a “watch” on any container or item even if you don’t own it and get notified. You’ll want to “watch” Task Reviews so that you get notified when people drop stuff into it.

The new feature coming is that you’ll be able to set a “watch” on any container or item even if you don’t own it and get notified. You’ll want to “watch” Task Reviews so that you get notified when people drop stuff into it.

Now I just logged onto the forum to request this very feature as it was bugging me that I don’t get notified of comment threads because I don’t own the task. Is it possible to automatically register a person if they make a comment on a feature. This is a common usecase and it would avoid the problem that a user comments on a task that they do not own and then do not get notification that an answer or counter comment has been made.

Regards

B