User customization of urgency calculation

[FilSalustri]

I find the urgency feature very useful.
While I can see why the various components of urgency are ranked/measured as they are, I find the specifics a little clumsy for my purposes.
In my case, I would like for scheduled dates to contribute more to urgency than they do.
I would imagine different users would easily have different preferences for urgency.

So I suggest some mechanism be provided by which users can alter the schema for calculating task urgency.
The details I leave to the developers - for instance, perhaps a modal containing a chart-like structure which displays the key values used to calculate urgency, or just having a single equation that users would provide, using predefined variables to name the specific components of the urgency calculation.
Whatever works best for the developers would be fine with me.

[claremacrae]

That's a great idea. Thank you very much indeed!

[Cito]

I'd would like the urgency feature to get more love, too. The default calculation should be more reasonable and it should be more configurable. See also #691 and #753.

[claremacrae]

The default calculation should be more reasonable

That's the thing I learned, though, when looking previously at the issues you linked. What is "reasonable" to one person is not to another... And so I could see no way to get an agreed new algorithm, and therefore it was not something worth spending my time on.

However, the nice thing about this alternative idea of making the whole calculation customisable is that I can stick with the current calculation as the default, and let individual uses get on with trying out whatever values they want... Genius!

[Cito]

Of course you're right that there is no "one right way" to make such a function that calculates a single score from multiple given dates and a given importance level. Yes, it is a difficult problem.

But I dare to disagree that this means there is no way to find out what is reasonable and what not, or that all the solutions are equal. If that would be the case we should not provide any urgency score at all. If you look at the examples I linked, you see that they all use similar formulas. And I think it really would help if the computer could make a reasonably good suggestion to help us prioritize our tasks.

Regarding "reasonable", I stubbornly stay with my opinion that it is ridiculous that a low prio task with a due day 10 years in the future should be considered more urgent than a normal prio one with no due date at all, which is what Task Warrior and the Tasks plugin currently do. I keep believing that it is possible to devise a formula/algorithm that is at least better than the current one and creates reasonable values - at least if you use the date and prio fields according to how they are named and how they are usually used in task management systems.

Of course I totally understand your reluctance to touch this part of the code, because of the complexity and ambiguity and the fear of making it even worse, or endless discussions with users like me on how to get it right.

Making it configurable with a parameter set or pluggable algorithm, and also displaying the urgency scores, could be a way out of this dilemma. Users could then play with various parameter sets, see the results and test them out in practice, and they could post their parameter sets. And if one these sets becomes popular and many users agree that it's better than the current default, it could then be made the new default.

[claremacrae]

@Cito I understood perfectly the first time.

Please understand that I am a volunteer who willingly offers my time to Tasks users for many reasons, including that:

• I use the plugin,
• and enjoy learning,
• and enjoy solving problems and helping people out.

When this goes well, I find it personally very rewarding.

or endless discussions with users like me on how to get it right.

Honestly, that is the crux of it.

I see from your GitHub profile that you are a developer and CTO. So you have been paid to program.

So I presume you will not be surprised to know that there are many, many months of improvements to Tasks that many, many users are requesting.
And many other things that I know will significantly improve things like the usability, performance, design, code maintainability etc...
Too much to do, and too little time.

Any one of those users who continues to re-explain the same points to me, in ever more detailed and condescending terms, especially about a subjective issue based on specifics of their use of Obsidian, is unlikely to increase the likelihood of my focussing on their particular pet area first, any time soon.

[Cito]

@claremacrae I get the impression that I annoyed you or came across condescending or you feel pressured or criticized. All of that was not my intention.

Yes, I get paid as a developer, but I have been maintaining open source software as side projects for many years without being paid for that work. I totally get that you are also working on this for free and for fun and nobody should demand anything or put pressure on you, no need to explain or justify yourself.

Regarding this issue, I just wanted to be helpful by linking to the discussions we already had and summarize what the issue was, not only for you, but also for others who may want to work on this issue. After all, open source software is also a community effort and discussion forums are made for having discussions about the things that are not so easy and obvious. Maybe as a result of the discussion among users, some good ideas will arise how to make this feature better. You can then still say yes or no to these ideas.

You complained that I re-explained my point. But on the other hand, you keep saying that my point is purely subjective and caused by my specific use of Obsidian, which is not the case and makes me feel I need to re-explain it again. You would certainly agree that ranking a lower prio task higher than a normal prio task is not what we expect, right? And making that lower prio task due in 10 years should still not make it rank higher, rather the opposite, right? What is subjective or contrived about this simple example?

Maybe my fault was to use the words "ridiculuous" or "unreasonable" to describe that behavior, when I should have used the word "unexpected". Sorry for that bad wording. My intention was not do devalue or offend, but to emphasize that the current sort order is the opposite of what any user would expect. I believe software should follow the principle of least astonishment, and this is part of the usability aspect you mentioned. Even if there may be no single best ranking algorith, there are certainly ones that produces less unexpected results.

I also don't understand why you think of the computational score (urgency feature) as just a "pet peeve" of mine. After all it's an officially documented feature, and reasonable ordering of tasks out of the box is the core essential feature of any task management software. Any time spent on improving that would not be wasted, and would make this software stand out and make it more useful. Again, this is just my opinion, and not an attempt to pressure you to put this on top of the agenda for this project.

Not sure how I can contribute to this project and this particular issue in a way that is more helpful.

[Cito]

@claremacrae Thanks, would be nice to work on this together. I can probably find some time next weekend or in the week thereafter.

It seems we agree that the best solution would be not to replace the existing algorithm with a new one (which might be better, but probably will still have flaws), but to make it customizable so that people can experiment with different formulas and share them with others. This is also a manageable task that is a lot easier than trying to devise the optional algorithm.

My only question is how flexible the customization should be and how it should look like. I will need to think about this a bit. Here are my current thoughts: If we provide a pre-defined function with configurable parameters or coefficients, it might still be not flexible enough. The most flexible way would be to make the user-defined JavaScript function completely replacable via configuration, which is possible since JavaScript is an interpreted language. We could document the input values and show some alternative example implementations in the documentation. We could also add some tests that verify that the example functions give reasonable (expected) results for some simple, typical sets of tasks. If users later come up with better formulas, we could simply add them to the documentation and would not need to change the implementation. Does this sound good to you? Any better ideas?

[claremacrae]

Brilliant. Thanks.

My only question is how flexible the customization should be and how it should look like

Thank you for thinking about it. From a quick read, I think we are probably thinking on similar lines.

But the fun thing about pairing: discussing and sharing ideas is way higher bandwidth and precision than typing back and forth via GitHub. Let's talk about it when we pair.

(Email address in my GitHub profile)

[Cito]

Actually, the function could have the same signature as the current urgency calculation function, i.e. take the complete Task as input parameter. It should be a pure function that maps the Tasks to a score value that is used for sorting. While the current function only evaluates the dates and priority, user defined functions could also evaluate other attributes of the task, like the path or description. That way, tasks in a certain directory could be automatically made more urgent and things like that. But we would leave it up to the users do define such rules.

[claremacrae]

Sounds good. We will need to avoid the temptation for perfection to be the enemy of existing, but I don't think you are going there...

[Cito]

But the fun thing about pairing: discussing and sharing ideas is way higher bandwidth and precision than typing back and forth via GitHub. Let's talk about it when we pair.

Yes, that style of collaboration certainly has its merits and can be very efficient and avoid the kind of misalignments we had. Let's try.

[claremacrae]

Current thinking is that instead of making urgency customisable, we go with the more general:
#1162

Introduce a new customisable score property, allowing any number of user-named algorithms

[claremacrae]

So I'm marking this one as 'no action planned' (because Discussions don't have the option of being closed)