I have been thinking I'd like to be able to tag entries (e.g. I'm working on issueX) and I'd quite like to be able to track estimates against a tag (e.g. I estimate it will take 5 hours to fix issueX, and I'd like to know how I'm tracking against that)
In https://github.com/samg/timetrap/issues/112 there was a feature request for keywords, which where there were different suggestions for simply using#tag and perhaps also a --tag option.
One way to do this would be to add an estimates table and a tag table then allow people to create tags, and then to assign a tag to entries, and finally to create an estimate, which would simply be a tag and target_minutes relating the two. There would need to be some thought around whether a new entry would automatically grab the tags for the previous one or not. There would need to be CRUD actions for estimates and tags.
You could do away with the need for a tags table, by simply allowing the estimates to take a regex and then using that in conjunction with the t d --grep functionality somehow.
Anyway, it's not exactly thought through yet. I might just build this myself as a very simple standalone estimates CLI and then maybe integrate it with a custom formatter somehow.
Now that I've written it all out, it does seem like quite a lot of work and quite possibly something you'd not want to integrate even if I did go and build it. Still, I'd be interested in your thoughts if you have time to comment.
Hi @samg ,
I have been thinking I'd like to be able to tag entries (e.g. I'm working on issueX) and I'd quite like to be able to track estimates against a tag (e.g. I estimate it will take 5 hours to fix issueX, and I'd like to know how I'm tracking against that)
In https://github.com/samg/timetrap/issues/112 there was a feature request for keywords, which where there were different suggestions for simply using
#tagand perhaps also a--tagoption.One way to do this would be to add an
estimatestable and atagtable then allow people to create tags, and then to assign a tag to entries, and finally to create anestimate, which would simply be atagandtarget_minutesrelating the two. There would need to be some thought around whether a new entry would automatically grab the tags for the previous one or not. There would need to be CRUD actions forestimatesandtags.You could do away with the need for a
tagstable, by simply allowing theestimatesto take aregexand then using that in conjunction with thet d --grepfunctionality somehow.Anyway, it's not exactly thought through yet. I might just build this myself as a very simple standalone estimates CLI and then maybe integrate it with a custom formatter somehow. Now that I've written it all out, it does seem like quite a lot of work and quite possibly something you'd not want to integrate even if I did go and build it. Still, I'd be interested in your thoughts if you have time to comment.