#1219
- Created on2011-10-28 00:33
- Reported by
- StatusMigrated
- PriorityNormal (3)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
option to reset staleness of action
This may be related to #759 and/or #1212.
Problem:
Less-important actions can pile up, and the staleness indicator loses its impact.
Solution:
Create an option to reset staleness on an action.
Example:
During my review, I find a task that hasn't been completed in two weeks. It's marked as stale, but it can wait another week or two. I don't want to defer it (move to tickler, remove from visible actions list), because I might get to it this week, but I don't want it to appear stale because it isn't very important. I click the action's drop-down, and select "Touch"; The staleness counter is reset for that action, and I can focus on more important things.
Problem:
Less-important actions can pile up, and the staleness indicator loses its impact.
Solution:
Create an option to reset staleness on an action.
Example:
During my review, I find a task that hasn't been completed in two weeks. It's marked as stale, but it can wait another week or two. I don't want to defer it (move to tickler, remove from visible actions list), because I might get to it this week, but I don't want it to appear stale because it isn't very important. I click the action's drop-down, and select "Touch"; The staleness counter is reset for that action, and I can focus on more important things.
Leave a comment
on 2011-11-07 19:51 *
By Nathan Plamondon
Assigned to set to Nathan Plamondon
Status changed from New to Test
Assigned to set to Nathan Plamondon
Status changed from New to Test
After a quick bit of research, I found an updated_at column in the todos table; Any reason we couldn't base staleness off that value?
on 2011-11-07 20:04 *
By Nathan Plamondon
Attachment staleness.diff added
Attachment staleness.diff added
file:c_N-racxSr4yTTacwqjQYw: Bases staleness on updated_at field
staleness is there to remind you that your next-action is not finished. There are several things you can do to an action in Tracks (like chaning contexts) that will change updated_at, while you still want to be reminded of stalling next-actions. So I do not prefer to use updated_at.
on 2012-01-18 18:16 *
By Nathan Plamondon
Attachment 201111292130000_add_touched_at.rb added
Attachment 201111292130000_add_touched_at.rb added
file:ctiEcKqGar4ADxacwqjQYw: Adds touched_at column to todos table
on 2012-01-18 18:16 *
By Nathan Plamondon
Attachment staleness.diff added
Attachment staleness.diff added
file:ctyFzIqGar4ADxacwqjQYw: bases staleness on touched_at timestamp
on 2012-01-18 18:17 *
By Nathan Plamondon
I've managed to create a touched_at column and change the staleness indicator to reflect that timestamp. Beyond that, I'm discovering that I'm not a ruby/js guru. Having difficulty figuring out how to add a new item to the todo context menu, as well as how to update the touched_at field.
on 2012-01-31 22:13 *
By Nathan Plamondon
Attachment 201111292130000_add_touched_at.rb added
Attachment 201111292130000_add_touched_at.rb added
on 2012-01-31 22:21 *
By Nathan Plamondon
Assigned to changed from Nathan Plamondon to -none-
Status changed from New to Test
Assigned to changed from Nathan Plamondon to -none-
Status changed from New to Test
todo context menu now shows a 'Touch' option, which will reset the item's staleness. If the touched_at field is NULL, staleness will be based on created_at.
on 2012-01-31 22:53 *
By Nathan Plamondon
I just realized that will probably choke without a public/images/touch_off.png. I'll work on putting one together this week. In the meantime, for testing purposes, copying another .png (I used to_project_off.png) to that filename works.
Isn't the review mode working for you? View -> Review
It might be confusing to the user to have two types of review in tracks: one at the level of projects and the other of individual actions (and only those actions that are currently actionable). If you do your weekly review at the level of projects, you automatically review all actions in the project and thus they aren't stale.
It might be confusing to the user to have two types of review in tracks: one at the level of projects and the other of individual actions (and only those actions that are currently actionable). If you do your weekly review at the level of projects, you automatically review all actions in the project and thus they aren't stale.
review page does not work for actions without a project and marking a project reviewed does not reset the staleness of the actions in that project.
I think, from a GTD point of view, there is something else going on. Why does an action get stalled? Either it is not a next action, in which case it should go to someday/maybe, or the stalled action is a next action you do not want to do (procastinate) or cannot prioritize. In all cases you should think about the reason it is stalled and take action on it.
So from a GTD viewpoint, I'd rather not add this function, but Tracks should not mandate GTD and there is enough demand for it...
I think, from a GTD point of view, there is something else going on. Why does an action get stalled? Either it is not a next action, in which case it should go to someday/maybe, or the stalled action is a next action you do not want to do (procastinate) or cannot prioritize. In all cases you should think about the reason it is stalled and take action on it.
So from a GTD viewpoint, I'd rather not add this function, but Tracks should not mandate GTD and there is enough demand for it...
looking at the patch, I think you should change the name of the button. I don't think non-technical persons will understand "Touch". Perhaps "Reset staleness"?
further, if you initialize touched_at to create_at at creation time of the todo, you can drop the check on nil in the staleness helper method
to keep the code consistent, please use Time.zone.now to fill touched_at in the touch method.
further, if you initialize touched_at to create_at at creation time of the todo, you can drop the check on nil in the staleness helper method
to keep the code consistent, please use Time.zone.now to fill touched_at in the touch method.
on 2012-02-02 20:59 *
By Nathan Plamondon
You're probably right about the procrastination theory. Between that and my difficulty figuring out how to set that value on item creation, I'm going to hold off on this feature. I'll reread the GTD review process and see if I can do without this.
I didn't mean to discourage you with the patch :-) We do not have a very good solution for someday/maybe other than creating a hidden context/project. Sometimes you just cannot prioritize it enough, therefore I think there is room to add the function...
I''ll pick up the patch and add setting the created_at for you.
I''ll pick up the patch and add setting the created_at for you.
Migrated to GitHub issue #1219