Best practice use of work item State and Resolution fields
We use a multi-step development workflow process that moves work items through various stages of Development, Quality Assurance, and Production deployment with accommodation for build requests, software deployments, and defect fixes in between. I am envisioning all these stages as "States" in RTC. However, a coworker envisions breaking these up between State and Resolutions.
What is RTC's intent of how State and Resolution should be used? Why does it matter? I assume if we follow RTC's intent and best practices we'll be better served in the long run. Are these best practices documented anywhere?
One answer
Comments
Thanks. I found the developerworks (2nd) link to be very useful for this question. (http://www.ibm.com/developerworks/rational/library/custom-work-item-rational-team-concert/) The other link for Changing RTC Process Configuration - Best Practices will come in handy as we configure the work items more.
I also found the following link that helped give some definition to state and resolution. https://jazz.net/library/article/42/
After reading these, it seems the resolution field is really intended to help document a work item that is in some sort of closed state. Does this mean it probably doesn't make sense to use the resolution field for Open or In-progress types of States?