Re: [BUG] Error in data input and output format for org-columns--summary-estimate

[andrea]

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" yantar92@posteo.net

A andrea@fedeli.eu

Cc emacs-orgmode@gnu.org

Data Tue, 18 Jul 2023 09:10:33 +0000

Oggetto Re: [BUG] Error in data input and output format for org-columns--summary-estimate

andrea@fedeli.eu 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>