Support for man-days and man-weeks
The estimation of projects is not very useful in current form if I got 5d 15h what does it mean in real life? More like 3 man-weeks 1 man-day and 7 hours.
It would be nice if project statistics would support md (man-day) and mw (man-weeks) with ability to set what man-day is (default 8h) and man-week (as 5*8h).
I'll be happy to consider a PR for this.
Let me know if you, the reader, would like to take a shot at this so that we can spec a bit how that should be implemented.
In the context of a todo list, displaying durations as 24-hours days is meaningless, even misleading if you don't immediately notice that something is wrong.
I think todo+ needs a settings Hours per day (e.g. 8) and then this piece of code that formats durations: https://github.com/fabiospampinato/vscode-todo-plus/blob/master/src/utils/time.ts#L46-L48 needs to use this settings rather than hard-coded values.
Weeks and years are a bit confusing in this context and to be honest I would prefer if it only sticked to days of work, even when it's 100 days. Otherwise I suppose 1 week = 5 days (do you need a settings? maybe 6 days in some places...) and 1 year = 52 weeks (to be honest at this point I think you would need more than todo+ to manage your project).
Hi, I'm also interessed by this enhancement. Hope it comes one day. Best regards.
Created a pull request: https://github.com/fabiospampinato/vscode-todo-plus/pull/220
Hi, I am also interested in such functionality. I can try to implement this, but I would like to decide on the approach.
As I see it, there are two options:
- Add the ability to configure the length of the day in hours (1 day = 8 hours), the number of days in a week, etc.
- Add new units, for example, man-hours and man-days ...
It seems to me that both options have the right to life, and each of them can fit certain scenarios. The implementation of the second option will allow you to plan simultaneously in a calendar format and in the format of human resources, which can lead to some confusion (what if some tasks are estimated in hours and some in man-hours?). Maybe we shoud have separate estimation one for calendar and one for human-resource (e.g. [est] and [man-est]) in this case?
Although the first seems simpler and more understandable.
@fabiospampinato @jods4 What do you think of it?
@proof666 I feel pretty much like you about this, I'd first try to add new units and see how it goes with that.
What about just displaying time in hours, not in larger units (days, weeks)? Couldn't we just transform anything above hours to hours before returning the amount for [est]? e.g. 25h15m instead of 1d1h15m or 123h30m instead of 5d3h30m or 1050h20m instead of 6w1d18h20m
I'd love to have the features outlined so far, with man-hours/man-weeks and [man-est] alongside [est], but it seems this approach is too complex for a quick solution. Estimates at the hour level are still very useful, even at large amounts (1000h).
@fabiospampinato @proof666 @jods4 @wimille What do you think?
@razvanges 👍 it would be a step forward as the total amount in hours is useful and more clear than an amount in 24h days.
Could be a settings to enable/disable this mode per user preferences, or maybe a new formatting token?
@razvanges I suppose we could add support for Moment's strings to todo.timekeeping.estimate.format, so that you could have it formatted as you please.
@fabiospampinato could be nice but I am not aware that momentjs has format strings for durations (it supports duration, but doesn't have a format method; it can format dates but that's not appropriate here)? Another lib might do the trick, though.
@fabiospampinato Using Moment's strings with todo.timekeeping.estimate.format would indeed give a lot of flexibility, but I am not aware of a way to define these scenarios (123h30m) by using Moment's strings.
Adding a new formatting option to todo.timekeeping.estimate.format, maybe called man-hours, would solve this issue in my perspective. And it could be reused for todo.timekeeping.elapsed.format, too.
Also, the same approach could work for man-days, plus an optional setting for its associated threshold (with 8 hours as default), to address the issue for @jods4 and the other guys.