projects need default due date, default 'show from'

[dnrce]

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

I created a project 'Christmas' to record gift ideas. I want them all to be due on Dec 25 and not to appear until about mid Nov. It's tedious to do that manually. There's not even a 'clone action' button that could help me.

Originally reported by Ben Jackson on September 9, 2009 at 00:30:24 (+0300) against version git-devel

[dnrce]

On September 9, 2009 at 03:50:11 (+0300), epall commented:

This seems to me outside the scope of todo management. Tracks isn't designed to keep track of arbitrary lists--there are other applications out there for that. If you'd like to see it happen, by all means fork on GitHub and show us what it would look like.

[dnrce]

On September 9, 2009 at 04:23:03 (+0300), Ben Jackson commented:

Is your objection to my specific example of using tracks to make a "Christmas" project with actions like "buy Joe a book" or the general idea in the summary ("default due date")?

Maybe a better way to express it would be to say that entire projects should have deadlines. For example, you might be going on a trip and all of the actions to get ready have to be done before the trip starts.

[dnrce]

On September 9, 2009 at 04:34:05 (+0300), epall commented:

If we're just talking project due dates, that's been discussed in #686. Personally, I wouldn't want a project's due date stamped on all of its todos. I'm not sure your use case is common enough to warrant cluttering up the UI.

[dnrce]

On September 9, 2009 at 04:34:20 (+0300), epall commented:

Duplicated association with ticket #686 was added

[dnrce]

On September 9, 2011 at 17:51:13 (+0300), popsch commented:

Projects need a 'show from' feature like individual actions. The 'due' is questionable, but the 'show from' helps you to reduce clutter on your home screen. This will be a very helpful feature.

[dnrce]

On September 9, 2011 at 14:54:18 (+0300), lrbalt commented:

I don't really get this. Adding a next actions means you can act on it now, so why hide it? I think the common case is not to hide it and hiding it is more the exception...

[dnrce]

On November 11, 2011 at 06:52:53 (+0200), popsch commented:

No, the point of 'show from' for a project is that you can enter the project as soon as you think of it, but do not show it until you can work on it.

You can achieve the same by entering the project and and then have a blocking todo as the first upon which all other todos depend upon, however, that's quite tedious to do with the current interface.

[dnrce]

On November 11, 2011 at 11:35:18 (+0200), lrbalt commented:

You alwasy have the option to hide the project which will not include the todos on the home page?

[dnrce]

On November 11, 2011 at 13:28:26 (+0200), cfrankct commented:

Maybe I'm overly sensitive, but it seems we're being pulled away from GTD.
In GTD your next action is determined by the context you're in, what's important and what you have energy for / interest in. Under that definition "not showing the project until you can work on it" can't happen, since that's what contexts are for. If I'm in the right context ('at computer') I can do my computer work, whatever project it may be for. If that's not the case then I haven't set up the next actions precisely enough.
On the other hand, if you like to use Tracks as a project management tool or generally to keep organized then due dates, show froms, extensive use of tags etc. make sense.
Personally I like the simplicity of Tracks and the discipline of GTD. I'm all in favor of filters that keep the UI (and the mind) uncluttered (i.e., don't show stuff you can't work on), but GTD will do that for you if you set up the contexts / next actions the right way and keep anything that's not immediately actionable either in the notes or a dependent action.

[dnrce]

On November 11, 2011 at 00:46:17 (+0200), lrbalt commented:

AFAIK from the GTD books, stuff you cannot act on now needs to go to Someday/Maybe and be reviewed in your weekly review. That's why hidden contexts / projects are in Tracks. Show_from implies you know you do not want to see the actions for a while, thus they should be on your someday/maybe list

The show_from construct on actions is for the tickler, not for postponing non-next actions.

So I agree with Christian that adding due_date and/or show_from to projects is pulling us away from GTD and into project management, which is not the goal.

A better someday/maybe constructs for Tracks is needed though to "park" ideas and stuff you cannot do now, but that is a separate (existing) ticket...

[dnrce]

On November 11, 2011 at 05:59:33 (+0200), popsch commented:

Of course there are alternatives of doing it. I just found the equivalent of the 'show_from' in the other GTD applications I used before moving back to Linux very useful. But well, I'll find a workaround for it.

I assume we can close this ticket then?

[C-Otto]

I think we should discuss the issue of having 'show_from' for a project. I think that having 'show_from' for the individual actions suffices.

When looking at dependencies #1425, the same issue arises. Does it make sense to have a project depend on anything (an action or another project)? I see many reasons to let an action depend on a project (where then the project's completion can be seen as completing the special and non-existing 'ALL DONE' action inside that project). But what does it mean if a project depends on something, assuming this project's actions do not share this dependency? If they share the dependency, what additional meaning does the project's dependency have?

[C-Otto]

(Sorry for talking about dependencies in here, but I feel this is strongly related)

It helps to think about two actions A, B where B depends on A. When now converting one or both of these actions into projects (with a few actions in them, each), how should the dependencies be modelled?

When transforming B into a project first, it may be the case that one of B's actions can be done even though A is not completed, yet. Thus, keeping 'B (the project) depends on A' and using this implicit dependency also for B's actions is a bad idea - at least that's what I think.

On the other hand, when transforming B into a project, it would be OK to just add the dependency to A to each action of B. For that, a 'add default dependency to A' GUI option would be nice, but this information is not a real dependency of the project (but, instead, something similar to the default context, or default tags of a project).

When first transforming A into a project, one could move B's dependency to the actions of A, but I think it is more intuitive to let B still depend on A (which now is a project).

In both scenarios, if one transforms both A and B into projects, things go well if the first transformation is done as discussed above.