[TW-82] Cross referencing task IDs

[taskwarrior]

John Florian on 2009-12-21T14:47:21Z says:

It would be useful if it were possible to do something like:

$ task add Put out house fire.
Created task 42
$ task add Fix fire hydrant.
Created task 43
$ task annotate 42 See also #43.
Annotated 42 with 'See also #43.'
$ task annotate 43 See also #42.
Annotated 43 with 'See also #42.'

The example is kind of lame because it suggests a dependency, but that's not really the intent. Obviously this can be done now, but if the IDs shift, the annotations will become incorrect. The gist of the feature would be that these somehow get adjusted behind the scenes. Present workarounds might involve a project or tags, but I can see cases where the projects are distinct. I suppose the annotation could suggest something like 'See tag foo'.

No pressing need now, just thought the idea warranted recording for future consideration.

[taskwarrior]

Migrated metadata:

Created: 2009-12-21T14:47:21Z
Modified: 2017-01-16T16:04:24Z

[taskwarrior]

David Patrick on 2009-12-21T15:31:42Z says:

this is directly analogous to RedMine's Related Issue links (look up) How about this ? if an annotation is a single numeric entry, and that entry matches an active task, then those tasks are related. or even, following the redmine example above, annotations could consist of

ann:related to 78 ann:duplicates 78 ann:blocks 78 ann:precedes 78

What happens afterwards is the interesting question, as to use this new link, reporting will have to be enhanced, again, and much discussion will be needed of how related tasks should behave and be displayed.

[taskwarrior]

Paul Beckingham on 2009-12-23T11:08:09Z says:

I love the idea of connected tasks. This feature keeps cropping up, and is highly desirable. There are problems though - while everyone agrees that task hierarchies, linkage, and dependencies are all things we want, no one has yet been able to put forth a sufficiently complete definition of what they are, what they do, and how they are used. We all want them, but only see them in a vague and ill-defined way. I would jump at the chance of implementing this, but not without a coherent and complete specification. That said:

Linking tasks would be straightforward to implement. For example, there could be a command like:

$ task 4 link 23
Task 4 "foo" linked to task 23 "bar".

Task would resolve the "23" to the UUID of the task, and create some link using the UUID. When displayed, the UUID would be replaced by a numeric ID for clarity. There would need to be a corresponding unlink command.

But before implementing something like this, we need to do a lot of analysis, and answer some very hard questions. They don't look hard, but just try answering them in a way that is sufficiently detailed and complete. Here they are:

1. Cardinality: Is linkage a one-to-one or one-to-many connection?
2. Commutative: Is linkage a two-way connection? For example, if 4 is linked to 23, is 23 implicitly linked to 4?
3. Transitive: If 4 is linked to 23, and 23 is linked to 30, is 4 linked to 30?
4. Differentiation: Do we need linkage types (related, duplicates, blocks, precedes for example)? Or is just one type (link) all that we need? The desirability of multiple connection types is balanced by the complexity of having different types.
5. What actions taken against task 4 would now affect task 23, and how?
6. Does 23 show up in reports that would otherwise show only 4?
7. Does completing 4 imply 23 is completed?
8. Does completing a linked task break the link?
9. How is linking tasks any different from assigning tasks to a common project, or applying a common tag?

Then there is the old dependency paradox I like to bring out:

• If task 6 is dependent on task 7, and I complete 6, is 7 automatically completed, or is completing 6 prevented?
• If completing 6 does not automatically complete 7, then what exactly does "dependent" mean?
• If completing 6 before 7 is not rejected, then what exactly does "dependent" mean?
• If completing 6 before 7 is rejected, then is task truly representing reality, when it says "7 depends on 6, you can't do that"?

This is our killer feature. Solving all this and coming up with a good linkage plan would be a major and dramatic enhancement to task, and would satisfy the bulk of all the (big) feature requests ever made. We could identify critical path. We could have estimates and estimated completion. We could make a really good "next" algorithm without the need for heuristics. We could have reports with natural groupings. The list goes on...

Can we do it?

[taskwarrior]

David Patrick on 2009-12-23T11:51:46Z says:

Paul Beckingham wrote:

I love the idea of connected tasks. This feature keeps cropping up, and is highly desirable. There are problems though - while everyone agrees that task hierarchies, linkage, and dependencies are all things we want, no one has yet been able to put forth a sufficiently complete definition of what they are, what they do, and how they are used. We all want them, but only see them in a vague and ill-defined way. I would jump at the chance of implementing this, but not without a coherent and complete specification. [snip]

Then there is the old dependency paradox I like to bring out: [snip]

Can we do it?

We can and will! In order for task to be truly relevant, and to reflect the actualities of task-doing, we will have to address linking and dependencies (aspects of the same thing) and it's going to be way hairy to reduce the lists, wants, wishes, use-cases, reconcile the project management dialects and best-practices, but we're not going to do it now, or even in the near-future.

Task 2.0.x +, with interactive ncurses interface, is the next thing up. It will quintuple the potential user-base overnight. In 2.1.x, the fuller feature-set of what-we-know-now of task, will find it's place in the interactive interface. These are foundational aspects for the future of the application, and contain lots of goodies, and will require lots of hard work and deep-thought. The dependency/linking subject is big enough to consume is all for months, just establishing the key specs, and if we are having that discussion with an interactive taskwarrior in place, we can focus on the nitty-gritty.

So let's keep the subject alive in the forums, and keep thinking and discussing how you think that should work, and let's get 2.0.x out the door.

[taskwarrior]

Paul Beckingham on 2011-07-11T06:08:09Z says:

Don't know if we can implement this yet, if at all. Deferring for now.

[ghost]

Am I correct in thinking that:

• this feature request predated the introduction of User Defined Attributes (UDAs) to TaskWarrior; and
• now that UDAs have been introduced to TaskWarrior, users who wish to do so may use UDAs to implement this feature request (i.e. to store, for any given task, a lists of tasks that are, in some non-specified way, "related")?

If so, then this feature request thread can be closed.

If not, then sorry for my interjection and please keep the thread open, thanks.

[ChargingBulle]

*distant thunder* It is time....

Back in the 2.0 and 2.1 days (way before my TW time) this issue was deferred until a later time. I'm not in the TW dev community but to me 2.6 looks very stable. Last commit was 4 months ago so I guess the ground is stable and ready for this.

I'll have a bit of ~famility time~ hobby project time on my hand real soon... How do I submit a TW RFC?

[ghost]

@JonasDralle wrote:

How do I submit a TW RFC?

https://github.com/GothenburgBitFactory/tw.org/pulls I expect, per standard GitHub practice :)

[ChargingBulle]

I have started drafting out a RFC. I will publish it as a draft as soon as it provides enough material to reason and discuss about.

This topic can be arbitrarily complex. I have one proposal which extends the concept of the depends-Property. It's easy to implement but might not suffice for replacing ticket relationships like Jira or Redmine have. Another proposal defines a separate "Link" entity governing relationships similar to a join-Table in relational database systems. It would be separate from the "task" entity I guess.

Those are the two extremes I have identified. I'm not sure what direction is more suitable for TaskWarrior.

@ddeimeke @pbeckingham Your inputs on this? Are there any previous proposals/discussions regarding this topic not visible in this ticket?

[ChargingBulle]

Also, in what way do I submit this? I have fleshed out the document structure but the content is soon to follow. Right now I am writing this in markdown. The page where the RFCs are listed seem to be a generated static site. Should I submit as txt/md/asciidoc/html?

[ghost]

@JonasDralle wrote:

The page where the RFCs are listed seem to be a generated static site.

I'm curious: what makes you think it was generated?

[ChargingBulle]

could be handwritten there's no <meta name=generator content="..."> tag. server identifies itself as Netlify via Response Header so I assumed it's hosted via netlify.com which seems to be some sort of static site generator. Unreasonable new lines are interjected into the code which is either from a generator or a sloppy HTML writer.

but none of this is concrete evidence. I just thought that manually writing HTML and ending every paragraph with </p> is against the "modern ethos". A single change in the overall layout would require the authors to make small modifications to hundreds of pages.

[ghost]

@JonasDralle wrote:

server identifies itself as Netlify via Response Header so I assumed it's hosted via netlify.com which seems to be some sort of static site generator.

Netlify provides static web hosting. No SSG necessarily involved.

I just thought that manually writing HTML and ending every paragraph with </p> is against the "modern ethos". A single change in the overall layout would require the authors to make small modifications to hundreds of pages.

Indeed. It is not DRY. But it seems to be how taskwarrior.org is currently maintained. I am sure someone will correct me if I am mistaken.

[ChargingBulle]

Okay. Doesn't matter right now. [...] I'd like to stay on topic...

_{EDIT: removed digression and associated embedded image}

[ghost]

Paragraph issue fixed. Thanks for spotting it.

[tbabej]

Website is indeed currently hand-written. We'd love for it to be a result of a static generator, there was an effort to achieve this from @svijee and @wbsch at some point.

[svijee]

Yep, I have some started work somewhere. I guess I/we need to pick that up an should start with some smaller iterations first.