[Patch] Show % complete for a milestone

[Ryan J Ollos]

The % complete measure shown for a milestone on Trac's roadmap page is calculated as (num closed tickets) / (num total tickets) * 100. This seems like a reasonable starting point for estimating % complete for a milestone, with the potential for more sophisticated calculations to be done in the future, such as using the %complete info for all tickets associated with a milestone.

Therefore I've modified the chart to show in the % complete column for milestones, the value calculated by (num closed tickets) / ( num total tickets) * 100.

In the future, the private method __get_milestone_percent_complete could be extended to support other calculations of % completion for a milestone.

This patch satisfies my needs, but if you want me to add options to control this behavior or make some other modifications, please let me know.

This patch also goes well with another patch I intend to make - determine the start and end dates for a milestone using the earliest start date and latest due date of any tickets associated with the milestone. Or perhaps, just make this change for the start date and continue to use the due date for a milestone. I still need to look more closely at this to work out a proposed plan.

Note: I also removed the comment FIXME - perhaps a closed ticket should always be 100% done. because it looked like this had already been implemented.

This change also ties in with #8947. If there is an option to group tickets under milestones, then especially in that case it make sense to show % complete for that milestone.

[Chris Nelson]

The closed/total tickets idea makes sense for tickets without estimates but if you have field.estimate and fields.worked configured/set, it seems what you really want is total hours in all closed tickets / total hour in all tickets. I think your patch is misleading if you are tracking hours. If you have two tickets in a milestone: a closed one with 4 hours in it and an open one with 24 of 28 hours remaining, you're not 50% done.

[Ryan J Ollos]

Replying to ChrisNelson:

The closed/total tickets idea makes sense for tickets without estimates but if you have field.estimate and fields.worked configured/set, it seems what you really want is total hours in all closed tickets / total hour in all tickets. I think your patch is misleading if you are tracking hours. If you have two tickets in a milestone: a closed one with 4 hours in it and an open one with 24 of 28 hours remaining, you're not 50% done.

I agree. I considered this to be a very simple implementation that mirrored the behavior of Trac's roadmap progress bar. Would you be interested in the patch if I extended it to use the estimate and worked fields in the case that they've been configured/set?

If so, we'll have to discuss the details of how this is implemented. For example, consider the following milestone with 2 tickets:

1. 8 hours estimated, 4 hours worked.
2. 8 hours estimated, 12 hours worked.

How should the % complete be calculated? If we just did hours_worked / hours_estimated, it would imply we are finished. We could, rather, calculate an estimate for each ticket using min( hours_worked) / hours_estimated, 1) and weight each by total_hours_for_ticket / total_hours_for_all_tickets_in_milestone. In that case, we'd get 75% complete for the above example.

[Chris Nelson]

Replying to rjollos:

... Would you be interested in the patch if I extended it to use the estimate and worked fields in the case that they've been configured/set?

Yes.

If so, we'll have to discuss the details of how this is implemented. For example, consider the following milestone with 2 tickets:

1. 8 hours estimated, 4 hours worked.
2. 8 hours estimated, 12 hours worked.

How should the % complete be calculated? If we just did hours_worked / hours_estimated, it would imply we are finished. We could, rather, calculate an estimate for each ticket using min( hours_worked) / hours_estimated, 1) and weight each by total_hours_for_ticket / total_hours_for_all_tickets_in_milestone. In that case, we'd get 75% complete for the above example.

This is a really tricky question that I fear comes down to business rules. We say that a ticket that is overestimate has 4 hours left so we have at least some cushion. We also work to revise the estimate so we have more reliable numbers.

If we has some sort of pluggable data provider, things like the Gantt or a scheduler would ask for "estimate" and get the padded value back rather than directly accessing the field. That's on my roadmap but a long way off.

[anonymous]

The recent commits listed #9301 may provide a technique to determine percent complete for a milestone based on estimate and work.