we are using PMF on our project and when we check in a rule we select the PMF task to which it belongs. In PMF we can now see on the task which rules where checked in which I really like. But what would be also great is the other way round. In the History tab of a rule we cannot see the PMF task it was checked in to. We wanted to enhance the history tab now, but the rule is final, so we cannot save it.
Would it be possible to add a column to the full history to show also the PMF task in addition to comments and Version?
thank you for your reply. Your screenshot is very small but I get what you meant. The problem is in our system the Task ID is not shown in the memo or anywhere else. The only place where I saw it was when we were merging a branch and checked for the conflicts. Thats why I was asking for the extra column.
The view changes option is good but only for recent changes. I am more interested in long term traceability. So when you see rule where changes were made half a year ago and you wonder why it would be helpful to look at the task in PMF which you can't if you don't see the ID.
I am just trying to understand what you would like to achieve with this functionality.
In my opinion a user story has a certain lifecycle. When its taken on in a sprint you will add the tasks and you can actually start delivering the functionality delivering what has been described in the story. When the user story is done and accepted in the sprint, its basically resolved. In next sprints you could have other tasks in user stories that also make changes to that specific rule. But what is the value of the taskid in a rule after the sprint? And what is the value of that after a year? And what is the value of a taskid in a reusable asset that is going to be reused by another team for another application that has no notion of the user stories it was originally created from?
I believe the feature of attaching the rule at check-in to a task or bug is handy for an overview of the touched rules. This can help to decide what to deploy, it can give you insight in what ruletypes are typically being changed/created or how many, etc. But as said; after the implementation (and acceptance) i dont see added value of knowing from what task, bug or user story it has been changed/created.
I know that to some people my suggestion makes no sense but we have a very big application that grew over time and sometimes you want to know the reason for a change that was made. And the best way to check is to look at the task / story where the reason / all the discussions are documented.