Make projects depend on actions/projects (a.k.a. nested projects)

[dnrce]

Migrated from the original issue at https://www.assembla.com/spaces/tracks-tickets/tickets/1425

I really enjoy how actions may depend on other actions. However, there are situations where projects may depend on actions (or even projects). In my opinion this corresponds to the idea that any action might evolve into a project at any time (Tracks supports that, yeah!), so dependencies should not only be a-a, but also a-p, p-a, p-p.

Originally reported by carsten.otto on May 5, 2013 at 19:06:19 (+0000) against version 2.2.2.git-master

[dnrce]

On May 5, 2013 at 10:28:53 (+0000), lrbalt commented:

Your idea is interesting

[dnrce]

On July 7, 2013 at 13:49:58 (+0000), carsten.otto commented:

I feel the need to clarify the need for this feature more, as I experienced many situations in the past few weeks where I'd love to make use of it.

For example, I am currently looking for a job. There are projects to create the CV, for the job application, for individual companies, for general questions, for finance issues, for moving issues, ...

Based on these projects I have a lot of actions (or even projects) that depend on completion of whole projects. For example, the project of moving depends on getting a job first. Some financial issues also depend on getting a job. The "get a job" project depends on the projects for the individual companies. Before sending an application to some company I need to finish the CV project. This example only covers a (big) part of my whole setup, but I have seen similar issues a lot in other aspects of my life, too.

All in all, I do not see any reason why there should be a difference between projects and actions (regarding dependencies).

I'd really love to help on this issue starting in 2014, if I find the time after my day job. Is there any other way how I can accelerate development?

[dnrce]

I think this better articulates #373.

[C-Otto]

Allowing actions to depend on projects (and actions) suffices. As discussed in #942 I do not see a scenario where a project needs to depend on anything.

[mattr-]

I don't agree with the idea that actions should be able to have dependencies on projects.

We don't mark projects complete automatically when all the tasks in a project are complete (and I don't think that's something that we should add). By adding dependencies between actions and projects, we're setting the user up for a scenario where the system will lie to them about not being able to do an action because the user hasn't gone in and completed the project that the action depends on. Yes, the system is lying to them because that's how the user has set things up, but I'd rather we not even place users in a situation where that could happen.

To illustrate with a more concrete example, I have two actions, Action A and Action B and a project Project A. Action A is in Project A and Action B is in a separate project that isn't important for this example. Action B could theoretically be done if Action A is done but we'll ignore that for now. Action B is set up in the system to depend on Project A. If I complete Action A but don't complete Project A until some time later, I lose out on the opportunity to work on an action that could be done because the system is basically lying to the user about that action being unavailable.

The counterpoint to my above argument is that the same thing can happen already today with action dependencies. This is absolutely true. GTD is an action based system and if you're not actively completing actions, then your GTD practice is failing, which is not something that the tool can really fix, which is why, for now, i'm ignoring the counter argument about the same thing already being possible with actions.

[C-Otto]

I don't think it helps much to talk about whether it is a lie or not, so I'd like to work around that word.

The point you're making is that users might be (or will be) confused in situations where an empty but not-yet-completed project blocks depending actions. This only happens if the user does not know about the difference, or maybe forgets it. Regular reviews could help, and maybe (just maybe) it would be a good idea to hint the user at empty projects in some more prominent way.

Do you think the fact that an action can be converted into an empty project helps thinking about this?

[mattr-]

I don't think it helps much to talk about whether it is a lie or not, so I'd like to work around that word.

You're right. "Lie" is not the right word here. The point I was trying to make is that, due to no fault on the user's part, the system isn't giving them the whole picture about all the possible actions that could be done.

Regular reviews could help, and maybe (just maybe) it would be a good idea to hint the user at empty projects in some more prominent way.

I definitely agree that hinting about empty projects better would be very useful. Good thing it could be done outside the scope of allowing actions to have dependencies on projects. 😃

Do you think the fact that an action can be converted into an empty project helps thinking about this?

I love that I can convert actions to projects but i'm not seeing how that is related to thinking about this particular feature. Was there something you had in mind?

[C-Otto]

I love that I can convert actions to projects but i'm not seeing how that is related to thinking about this particular feature. Was there something you had in mind?

Yes. Think about action B that depends on action A. Now action A is transformed into a project. In the current code, the dependency is (silently) dropped. If dependencies from actions to projects are implemented, this could be retained.

Especially for actions that (over time) evolve to multi-action projects, losing the dependencies is annoying, depending on the complexity this could also be frustrating (this happened to me in the past). If you start with a rough sketch of actions that lead to some goal, and some of those actions actually are projects, this is a common scenario.

Please also have a look at the discussion for issue #942.

[C-Otto]

At the moment I'm mostly concerned about the internal data model, not the UI, nor the user experience. All of these aspects are important, but I don't think it is helpful to discuss all aspects at once.

As another thought, it might be helpful to display a magic "ALL DONE" action in each project. Marking this action as complete automatically marks the project as complete. This action automatically depends on every action in the project (including new actions, or actions moved into the project, updated if actions are removed/moved/deleted/completed) and, thus, is only shown as active if it is the only remaining action in the project. In the database this special action does not appear at all, but its information is computed based on the project properties. The dependencies can be modelled, as suggested, from action to action and from action to project.

[mattr-]

All of these aspects are important, but I don't think it is helpful to discuss all aspects at once.

User experience is perhaps the most important aspect of this feature, IMO. If the user experience is poor and/or we implement this from the frontend side of things poorly, it doesn't matter how awesome the internal data model is.

As another thought, it might be helpful to display a magic "ALL DONE" action in each project. Marking this action as complete automatically marks the project as complete.

That's not a bad idea, but i'm concerned about the noise in the database if we do end up implementing something like that. Or would the 'All done' action just be a facade and not be backed by the database at all?

[C-Otto]

This was explained in the same paragraph:

In the database this special action does not appear at all, but its information is computed based on the project properties. The dependencies can be modelled, as suggested, from action to action and from action to project.

The only addition/change here would be allowing dependencies from actions to projects. The project itself does not need to be changed.

[mattr-]

This was explained in the same paragraph

Welp, that just confirmed that I can't read. 😉

Dependencies on projects are not the GTD way™. Tracks is designed to be a GTD tool vs. just a general project management or todo list app. I'll consider a pull request to add them though.

[C-Otto]

While we're at it, are dependencies between actions the GTD way? In my opinion both dependency options are just a fancy UI tweak, and not related to the core GTD method.

I'll work on a PR, as soon as the state cleanup (#1981 etc.) allows for this.