Opened 3 years ago

Last modified 3 years ago

defect #78 (closed: wontfix)

Completion Sizes Get set to 0 whenever I resolve a ticket fixed

Test Complete Size: 0 Test Complete Date:
Documentation Complete Size: 0 Documentation Complete Date:
Acceptance Complete Size: 0 Acceptance Complete Date:
Reported by: jmiller Owned by: ja11sop
Milestone: Undecided Component: agile-trac.org
Version: Keywords:
Cc: Blocked By:
Patch SVN Revision: Patch Trac Version:
Blocking:
In Iterations: 17

Description

I am not sure if this is is truely a defect or I am using the tool incorrectly, but basically this is dimishing our ability to use the progress bar because as tickets get complete the size of the iteration reduces

Change History

Have a look at the list of modified files related to this ticket.

Changed 3 years ago by ja11sop

  • test_complete_size changed from undefined to 0
  • doc_complete_size changed from undefined to 0
  • acceptance_complete_size changed from undefined to 0

Ok - you're highlighting that there is really minimal (almost non-existent) details on how to use agile-trac.

Here is a basic workflow.

  1. Create new work (user story, defect, etc.)
  2. size the work
  3. When one stage of the work is complete you progress the work by entering a date when the work was completed.
  4. If all non-zero sized stages are complete then the work is automatically resolved as done.

Now it is possible for you to additionally resolve work directly. However if you do so all the sizes are reset to 0. This means that the work has been completed but that it does not contribute to the meaningful progression of sized work. We don't have a completion date for any stage of the work so tracking the size of the work has no meaning here.

Typically this means that you want to remove the fixed resolution from the set of possible resolutions. Otherwise people will inadvertently use it to signify completion of work. Now there are many clever things that could be done if you leave fixed (or something that means fixed as a resolution, but these are overly complex.

Instead it is better to reserve the use of the resolve action for those resolutions that signify that you will not be spending time on the issue. For example, worksforme, wontfix and duplicate would all fall under this category. I really need to put this and other documentation together in a single place to make migrating to agile-trac easier.

Thanks for raising this issue. I'm resolving this as wontfix as this is really as-designed. Please feel free to comment more on this and I hope my explanation makes sense to you.

Note: See TracTickets for help on using tickets.