task diag command.work
work.marketin
work.development
personal
personal.fitness
personal.shopping
and so on.
I have personal goals each week for how many hours I devote to various tasks. It would be very handy to establish a set of rules such that each time a task was assigned to a given project, it would be auto tagged with a set of tags that could be specified in .taskrc.
WHY YOU ASKK?
I'm so glad you asked.
Well then I could do things like
timew week +marketing
timew week +personal
timew week :lastweek work
so I could filter how much of last week was spent on work, how much was spent on personal tasks... and I wouldn't have to remember each time to tag my time correctly, or hope that my description of the task contained the category of time I truly consider it to be in.
It would also be helpful to be able to specify more than one tag for a given project name.
You have described an ideal use-case for an on-add hook script.
If a feature can be implemented using a hook script, we are unlikely to add that feature to the core program. Unless it is proven to be a valuable enhancement to task management. I say implement this as a hook script. If it works well for you, and others, we can share the script. If it could be improved by moving it into the core, we'll do that. One step at a time.
@pbeckingham agreed that this is good for a hook script. I wonder about the best way to handle feature requests given that many of them could be handled by hook scripts. Wondering if another repo with hook feature requests issues makes sense. Or point all feature requests to another place and pluck ones eligible for core from there.
I generally like to promote letting Github reactions (or similar votes) influence feature development. Just because something is best done by a hook script doesn't mean the submitter has to implement it, and if I was feeling like coding a new feature I'd find it worthwhile to sort thru possible hook features for a highly-demanded one so that I could contribute a feature that people want.
But leaving this open when it's not considered for core might clutter the issue tracker. And if it's closed, then people won't be able to find it as easily since it'll be mixed in with completed features.
Hope that wasn't too confusing.
Closing this as use-case-for-hook.
Most helpful comment
@pbeckingham agreed that this is good for a hook script. I wonder about the best way to handle feature requests given that many of them could be handled by hook scripts. Wondering if another repo with hook feature requests issues makes sense. Or point all feature requests to another place and pluck ones eligible for core from there.
I generally like to promote letting Github reactions (or similar votes) influence feature development. Just because something is best done by a hook script doesn't mean the submitter has to implement it, and if I was feeling like coding a new feature I'd find it worthwhile to sort thru possible hook features for a highly-demanded one so that I could contribute a feature that people want.
But leaving this open when it's not considered for core might clutter the issue tracker. And if it's closed, then people won't be able to find it as easily since it'll be mixed in with completed features.
Hope that wasn't too confusing.