Agree absolutely. It is logical. You have issues, which are not identical with tasks. If they were, then you needed no issues. Issues differentiate by the fact, that they are not assigned directly to somebody.
Option 1: In the moment you assign a ressource to the issue, the issue is converted to a task and the issue is deleted/cancelled.
Option 2: The issues always will be existend unless the status is not set to "resolved". But then the requested functionality to link it to a task is more than logical.
Unimportant which of both opitions projectplace decides to follow, as long as not one of both options is implemented in projectplace, there will be an inconsistency.
Hope, you consider this also as being necessary. Go for it, you can. ;-)) Time for a change. ;-)
Regards,
Joachim Schirra
Very important idea! It would be very efficient if you could create and follow-up Issues in the "Task-view" for each sub-task. You then introduce more understanding of what you do in your project and where you are within the completion of each task. As mentioned in previous comments: you need to complete several Issues to complete a Task. The connection is obvious, but today both these views seems to live their own lives....A lot of hard work to use both tools according to me and my collegues. It is hard to motivate people to use Issues. Using the Task view is easier to motivate since it is obvious that we need to structure the project and follow-up the degree of completion in each sub-task, to be communicative (at least). Why not do all follow-up in the same view, keep it together and get it more understandable?
Paul voted
An anonymous voted
Per voted
An anonymous voted
Alex voted
An anonymous posted a new comment
An anonymous voted
An anonymous voted
Silvio voted
Silvio posted a new comment
Karolina Wicksén Jackson-Ward
Ideas with status Business Case require a bit more development and might affect several parts of the system. These will therefore have to be prioritised against other new development. The way we do this is by writing a business case for the development and then discussing the prioritisation of the business cases. We write business cases for the top ideas in this category.