`weight' property for tickets

[georg-wicherki@…]

Trac already includes a great feature for Milestone progress: the count of tickets. However, single tickets can contribute more or less to the progress of a certain Milestone, for example a correct spelling mistake' is much less to code than a complete core rewrite'. If these both tickets are the only two for a milestone, and the spelling mistake is set to resolved, Trac will show the progress to be 50%.

A weight property of tickets, only editable by developers and which defaults to 1 could easily solve this issue. A ticket with a weight of $x simply counts for $x tickets.

[jonathon.jongsma@…]

Personally, I think this would tend to clutter the interface and add complexity for not much benefit. I think if this was to be attempted, a better approach would be to allow administrators to assign a 'weight' to each severity (but I think the default should still be have all severities weighted the same).

This isn't perfect, of course, because there isn't always a direct correlation between severity and effort (i.e., there could be a bug with a severity of 'critical' that's the result of a simple typo), but I think this is partly caused because severity is not used consistently. The default severity 'trivial' clearly implies that it doesn't require much effort to fix. The default severities 'minor', 'normal', and 'major' can all be correlated to either effort or to how much impact the bug has on the program; and the severities 'enhancement', 'critical', and 'blocker' really can't be correlated to amount of effort. Rather, they seem to imply some combination of priority and impact on the program. For example, does anybody ever mark a bug with a severity of 'blocker' and a priority of 'lowest'? It doesn't seem likely.

I realize that the default choices for severity are there for historical reasons, but maybe the concept of severity needs to be refined and made more consistent. Or maybe it's not worth wasting that much time over :). I will say though that if the original request is deemed to be a better approach, I would much prefer a field called something like "estimated effort" than "weight".

[Matthew Good]

#1565 has been marked as a duplicate of this ticket.

[trac@…]

I don't agree with Jonathon that severity can be used to accomplish weights. Most project managers will want to assign an effort to tasks that do not correspond to a linear, discrete scale required by the severity workaround (especially when you consider that severity will likely disappear — see TicketTypes).

I don't think, however, that the milestone feature should be changed to implement progress this way. Instead, the measure of how complete a milestone is should be customizable on a ticket's field. Then custom fields could be setup for effort and then summed for the milestone progress.

[sid]

With the addition of milestone stats extension (see #2314) into trunk (and adding a weight custom field), this should now be possible to do with a plugin.

[Christian Boos]

This should eventually be done as a plugin.

[Christian Boos]

#6230 was closed as duplicate.

Note that in 0.11, there's an interface which could be used to write a plugin to do this: ITicketGroupStatsProvider, see source:trunk/trac/ticket/roadmap.py@6080#L43​ and #2314.