Hi, a big hope of mine is to see Wrike evolve a complete approach to cross-referencing and liking among the key data types in the tool: Projects, Folders, and Tasks. I leave out Sub-tasks, as you guys have done a great job with sub-tasks and their functioning for all intents and purposes as tasks.
I have voted on a feature request that captures some of this here: https://help.wrike.com/hc/en-us/community/posts/115002961109--Linking-to-projects-tasks
But I thought it might be useful to lay out a broader outline of how these features would come together. Forgive me if this is repeating something that's out there as a request, but I have looked long and hard and did not find anything summarizing as I plan below:
References as a basic task description field:
It would be very powerful if there would be an extra field in each task and project header showing related tasks. This could collapse like subtasks and fields if there are multiple references. The user could simply go to this field, and start to type, much as you can already do in subtasks, and have any project or task start to pre-fill. Once the desired result was found, that task would be chosen and linked.
It would also be great if you could start typing, as in the subtask field, and create the task if it is not found with at "+" symbol.
Back in the linked task, in its equivalent "reference" field, that reference would also be picked up.
This field could also be used for a task that converts to a project, or vice versa, should that feature be developed that is being actively talked about here:
This field would also pick up tasks that come into another task/project via @mentioning a task in comments or descriptions, which is the request in the link I posted at the top of this message. So if you @mention a task or project, perhaps with a new command such as "ctrl" + "K" or "/" which are common in other programs, that reference would automatically get picked up in the Reference Field I describe.
So in effect, the result is this:
- There is a new "Reference Field" on each task/project/folder that will reference related tasks/projects/folders
- In order to create a reference, it's enough to type one into the field, create one when typing in the field with the "+" I propose, or @mention within the description or comment field, if that feature comes out.
Another subject are the types of related links that tasks could have in relation to each other. Jira has a great feature and lets you actually create your own types of links (!). That would be terrific, but short of that, some examples could be:
- is caused by
- discovered during testing
And as a last word in this proposal, I wanted to suggest that the existing dependency field seems like an easy way to add this linking by creating a "non-dependent" link. I don't want to suggest development solutions to you guys, but since you already have this functionality with dependencies, it strikes me that the easiest way to add this to the Wrike feature set may be to use this existing piece.
As far as use cases, there are too many for me to list on my own, but some that come to mind:
- "follow on" task - as you complete a task and realize another one has come to mind, you can link via these links, and see both the original and follow on
- If a task is cancelled, but a related task results, and you may want to write a comment and keep the cancelled task for reference, instead of deleting. It is very useful to see the cancelled task that led to the "real" task
- Meeting notes - huge. This functionality would allow for meetings to reference both projects and tasks, and also clearly be shown as the moment of creation of task/project ideas. There would be no more "who decided that" as anybody in a task can click the meeting reference and see what was discussed in a note made in the meeting task itself.
I hope this post does a useful job of consolidating this request, and I hope a lot of other members will weigh in and augment where necessary. Thanks for listening!
- Bug tracking - "Discovered in testing" is a very relevant use of task linking, as well as relating a bug to a task that a team may be using to represent a software feature - my team does this.