Opened 16 years ago
Last modified 8 years ago
#7884 new enhancement
Ticket should contain a field for the expected time to complete/fix it
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | next-major-releases |
| Component: | ticket system | Version: | none |
| Severity: | normal | Keywords: | fieldrefactoring |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
This would give a number of benefits, and among them:
- a (super)user that has the rights to change the priority of the tickets can rearrange them based on the time to handle them
- a milestone could show an expected time to be completed as the sum of the time of each ticket
Attachments (0)
Change History (8)
comment:1 by , 16 years ago
comment:3 by , 16 years ago
| Keywords: | fieldrefactoring added |
|---|---|
| Milestone: | → 0.13 |
| Resolution: | → fixed |
| Status: | new → closed |
Related to FieldRefactoring.
comment:5 by , 16 years ago
I would really like to see this feature implemented. But get it right. I think #7936 expressed the requirement better from my point of view. Just to point out a few things:
- I prefer Story Points, or something that expresses complexity. It is better for planning: Often a release date is set and I have to choose which tickets to finish before that date. With a Story Point it is easier to estimate if the work set for a milestone is realistic.
- In my case there is little room for negotiating release dates. The Story Points should show as a sum for a milestone, but I don't want the date to be calculated from this.
- Progress should be calculated from Story Points. The progress bar now shows the same progress weather the ticket took an hour or a week to solve.
- There is often confusion so to be clear: I do want estimation, I do not want time reporting. Estimation is good for planning, time reporting is just lame.
follow-up: 7 comment:6 by , 14 years ago
While #1942 is about 'time', this is one is about 'duration'. The storage would also be in usecs, but the display would be in day / hours / minutes, as appropriate.
comment:7 by , 12 years ago
Replying to cboos:
While #1942 is about 'time', this is one is about 'duration'. The storage would also be in usecs, but the display would be in day / hours / minutes, as appropriate.
Now, that we have 'date' and 'datetime', why not make 'duration' a third time field format? It might require more formatting options than current relative time formatting, but IMHO it nicely fits into the family.
comment:8 by , 10 years ago
| Status: | reopened → new |
|---|
#7936 marked as a duplicate