Howdy!
I'm back to a previous element partially discussed as I found other org
places where the duration had to be adapted to be able to deal with ranges:
org-clock-get-clock-string and
org-clock-notify-once-if-expired, both in og-clock.el; both get into action
if you have a task you estimated and for which you're now tracking development
time (quite handy, I have to say, as you're immediately warned you've running
beyond estimations. For those two functions, I have introduced a similar change
to the one I did originally to go from the basic string-to number on
split-string to org-duration to minutes. Thanks, Sant Ignucius, for the
debug-on-entry feature :))
Two considerations here:
1. I understand the fact that est+ doesn't have to necessarily be associated
with effort, but it is quite clear from the docs which is the intent with which
it was introduced: the only provided example is on times, and there we have to
consider that time is expressed in durations.
What I mean is that it does NOT make much sense to me to tell users the
effort is to be written as 3d if given as a single value, and it has to be
rewritten as 3-5 if we want to say "in a fork of 3 to 5 days", especially if
somewhere else some other duration unit is used..
2. Said differently, whether it was practically used also somewhere else,
and not for time estimation, I can say nothing about; it is already quite hard
to find it in doc, to date, and there the only example given is about time.
As without my changes the effort fork would not work properly in org-clock
functions, if we really think estimation ranges shall be used also somewhere
else I think we need to consider a possible generalization of what a duration
is. In facts if we want to utilize it for other kind of measuring units
(weight, money, etc.), it might make sense to pair it with a proper translation
table like the one of duration that allows to convert days, hours, weeks, etc.
into minutes, back and forth; this way we might allow both a proper type check
according to the utilized measure unit, and would be able to avoid having to
misleadlingly allow to sum tons to kg, for instance. (Recall: the ending letter
today is just discarded hence 1kg-1ton is today taken as 1-1).
Cheers,
Andrea.
Da "Ihor Radchenko" [email protected]
A [email protected]
Cc [email protected]
Data Tue, 18 Jul 2023 09:10:33 +0000
Oggetto Re: [BUG] Error in data input and output format for
org-columns--summary-estimate
[email protected] writes:
>> About possibile abuses, org documentation, to date, clearly tells
>> org estimate utilizes times.
>
>> May you please elaborate?
> AF: Sure! Clause 8.5 of current
> (2023.Jul.14) org documentation,
> https://orgmode.org/manual/Effort-Estimates.html, refers to effort
> estimates giving examples that are all appearing to fall in time
> domain.
I see what you mean.
However, est+ column summary does not have to be applied to EFFORT
columns.
One can, for example, use %SCORE{est+} column specification to summarize
values stored in SCORE property. Org has no right to demand SCORE to be
in time units and only time units.
> > Similarly, I'd not spend too much code to check the format; i
> > understand the intent to preserve backward compatibility, bit if
> > that format adaptation mistake slipped forward to these days I
> > doubt that nice feature was used much so far...
>
> Yes, but it is easy to have a fallback, so why not.
> Because this way you persist in allowing a mistaken usage of that
> function. A number is a number but a duration is NOT just a number,
> and having something like (just for example) 10kg-0.5ton be taken
> as 10-0.5 is in my opinion NOT helpful to any user.
We may provide a linter (for M-x org-lint) that will ensure EFFORT
estimates to be in understandable format.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
