Fixing setting size fields to 0 is unexpected

[ja11sop]

There are some notes on this here Tickets should be progressed until they are `DONE`, rather than resolving them. However to expand a little on that. The idea is that we need to be able to distinguish between tickets that are DONE (implicitly resolved as DONE because all stages are complete) and those that are simply resolved. If we make it possible to resolve a story and have it complete also, then we need to base that decision on the name of the resolution. For example if the resolution is fixed. Right now we have a uniform approach to this. Now, it may make some sense to allow the user to specify certain resolutions that have an implicit progression behaviour, so as you suggest using fixed to imply that all stages are progressed with the current date, resulting in a ticket in effect being progressed to a resolution of DONE (not fixed). But it starts to get a little complex so the default recommendation is to simply to rename or not use the fixed resolution. Not ideal but the cleanest approach at the moment. After all we are asking people to use agile-trac in a few fundamentally different ways than how they would use trac. It might make sense to provide some examples of commit scripts that do progress the test_complete stage. I don't do this myself as we tend to have more than one commit for a given story.

[ja11sop]

At a minimum this requires clearer and more prominent documentation, hence the doc_complete stage having a size added to it.

[dfraser]

The standard trac svn post-commit hook is at  http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook. This allows you to specify either:

• Referencing a ticket: See #108, Re ticket 108, etc, or
• Fixing a ticket: Fixes #108, closes ticket 108 (with a few variations in syntax).

So typically all except the last commit would simply reference the ticket (which adds a helpful comment referring to the changeset and including the message), and the last commit would state that it fixes it.

So I agree since agile-trac is fundamentally different, we probably need different workflow here, and it's not too hard to do. This could be done by extending the concept to allow completing stages:

• Referencing a ticket: See #108, Re ticket 108, etc, or
• Completing a ticket stage: Completes testing #108, finishes ticket 108:documentation (the syntax is the tricky thing).

Is there a standard way of referring to a ticket stage? It's not something that's trac-linkable so this is what's up for debate here. In my case the best thing to do is probably to change the svn hook to make it complete the testing stage rather than marking the whole ticket as fixed. Perhaps we could include such a modified svn hook in a contrib directory on agile-trac.org similar to the one from trac?

Also, if the proper workflow is to be followed, rather than allowing users to simply mark an issue as fixed and destroy the sizing info, it may be better to require them to supply complete dates for stages when making such a change. This brings up the whole issue of how sizing and stage completion should interact with the rest of the standard workflow, which I'll leave for now :-)

[ja11sop]

Replying to dfraser:

So I agree since agile-trac is fundamentally different, we probably need different workflow here, and it's not too hard to do. This could be done by extending the concept to allow completing stages: * Referencing a ticket: See #108, Re ticket 108, etc, or * Completing a ticket stage: Completes testing #108, finishes ticket 108:documentation (the syntax is the tricky thing). Is there a standard way of referring to a ticket stage? It's not something that's trac-linkable so this is what's up for debate here.

It would probably make sense to either use the existing stage name from the trac.ini file or allow a shorter form to be specified to make it easier to type. Getting the syntax right will require a little thought. We can throw out soe more ideas later, in addition to the ones you already captured.

In my case the best thing to do is probably to change the svn hook to make it complete the testing stage rather than marking the whole ticket as fixed. Perhaps we could include such a modified svn hook in a contrib directory on agile-trac.org similar to the one from trac?

Yes - I think that is a very good idea.

Also, if the proper workflow is to be followed, rather than allowing users to simply mark an issue as fixed and destroy the sizing info, it may be better to require them to supply complete dates for stages when making such a change. This brings up the whole issue of how sizing and stage completion should interact with the rest of the standard workflow, which I'll leave for now :-)

Yeah it may not be as hard as I expect but one thing I toyed with was simply removing the resolution during the upgrade and makig documentation better. It can always be added back in later, but by then I would imagine there was a better appreciation of what the intent was. At least now it is pretty easy to progress stages now using the date picker.

From reading this I am beginning to think we should capture this as a separate story that deals with svn commit hook integration? This will still remain valid though as I think there should be documentation improvements for the existing functionality.