Re: [tasklist] Done/PercentsComplete

On Thu, 2003-02-20 at 04:43, Tim Lebedkov wrote:
> Hi,
> 
> It is now possible to have a task that is done but it's percentsComplete
> returns 0.

Really?   Here's the implementation of setDone() (which is called when
you toggle the Done checkbox)

    /** Set status of the task to be "done" or "not done".
     * Will also set the percent complete to either 0 or 100.
     * @param done Whether or not the task is done.
     * @todo Consider using percent complete instead. */    
    public void setDone(boolean done) {
        this.done = done;
	percent = done ? 100 : 0;
        ...

Likewise, in setPercentComplete()
    /** Sets the percentage complete for this task. Will also
        update the done flag for this task. */
    public void setPercentComplete(int percent) {
        ...
	this.percent = percent;
	// Keep Done in lockstep
	this.done = (percent == 100);
        ...

> 
> Here is how I want to change it:
> 1. done() means percentsComplete() == 100

I agree, and this should already be the case, right? (Or am
I missing something?)

Ah, you're suggesting we can just get rid of the "done" boolean
field and replace it with (percent == 100) ?  Sure.  Note how
isDone() is implemented however; it tries to be graceful about
handling subtasks.

If you mark a parent task done, all its subtasks are marked done
as well. However, if you change your mind and set it back,
the previous state of done for all the children is remembered:

    /** Indicate if the task is done; if any parent task is
     * done this task is considered done as well.
     * @return true iff this task is done; if the parent task is 
     * marked done, so will this one be. */
    public boolean isDone() {
        if ((parent != null) && (parent instanceof UserTask)) {
            return ((UserTask)parent).isDone() || done;
        } else {
            return done;
        }
    }

> 2. if a task hasn't children it's percentComplete value is used
> 3. if a task has children then it's percentsComplete() returns average of
> children's percentsComplete()

Interesting idea. When we get estimates for tasks (for project
scheduling), these should be weighted by the estimates.

In other words, if I have 2 subtasks
   task A: complete 0%, effort=100 hours
   task B: complete 100% effort=500 hours

then since task B is 5 times more work than task A, and
we're done with it, percent complete is not the average (50%)
but the weighted average (83%).

BUT.

Note that percent complete is an editable property. Note also
that there is no requirement that when a task has subtasks,
the set of subtasks forms the complete task.

1  - implement feature A
2  - implement feature B
3  - fix bug C
3a   - check if C is the same as bug G
4  - fix bug D

I think this is valid usage of the tasklist, but notice how
if subtask 3a is 100% complete, the "average" from the children
will be 100%, so "fix bug" will be marked 100% done too, not
the intent.

Also note that the user can go and assign a priority complete
to this task (task 3), let's say 46%. How does this interact
with the averaging algorithm?

Perhaps a compromise can be to ask the user. If you edit the
priority for a subtask, (recursively) ask the user if they
want to modify the parent task's percent complete as well -
and here a textfield or slider can default to an average
or weighted average.

-- Tor

P.S. I think 
        progressBar.setOpaque(false);
in PercentsPropertyEditor makes the progress bars look better when
shown in the table; that way it keeps the white background in the
table, and gray in the property sheet. I noticed you've already done
this for the checkbox.  Great work on the property editors!