No sooner thought than implemented. I’ve uploaded a template Tinderbox autodata engine to my fork of the bmndr script.
You should be able to copy/paste the entire ‘Beeminder’ note into your document. Move it to the top of the outline view (to avoid name clash) and change the configuration. If you have an agent update $Subtitle("value") then it’ll get submitted to Beeminder whenever the value changes (at most every 5 minutes).
I haven’t updated the above linked code for ages, because the one that gets tweaked is the one embedded in my task list. It’s now more efficient, but it’ll take some effort to extract. Doubtless there will be more changes now that they’ve fixed the ‘edict’ feature, in Tinderbox 6.3.1.
@philip, any thoughts on whether it’s necessary to sum the squares of the ages instead of just summing the ages? The latter is what @galtsubery implemented for beemind.me.
Hard to say. Squaring the ages increases urgency and forces hard decisions. Often the decision is to firmly push an item out of the ‘ought to’ pile down to the ‘possibly never’ pile. Much better for me, psychologically, to decide not to do something than to leave it on the list.
More important is that I use urgency-adjusted ages Not everything on the list is equally important, and the unimportant/non-urgent stuff inevitably overwhelms the volume. The downside of putting things on a single list is that everything implicitly gets the same weight and importance.
It can be frustrating how quickly (and unintuitively) the sum-of-squares adds up, partly because it’s hard to predict whether tomorrow will be a beemergency. From that perspective, summing the unsquared ages has an advantage. But I’d want to preserve the relative importance of items.
The reason you want to use a power is that one 12 month old task is worse to have around than 12 one month old tasks. The power factor lets you easily include this in your calculation. But you don’t need to use 2. Instead of n^2 you can use a number less than 2 to get one that doesn’t run away so quickly.
That’s not obvious to me (though maybe it will become so after I beemind it for a while). I mean, without squaring you already have the effect that a 12-month-old task is 12 times worse than a 1-month-old task. Maybe that’s enough?
Say I have a 20-point beemergency. If there are tasks that have been starving for weeks then I just need to dispatch one of them and I’m done, versus maybe 10 new tasks. But maybe the point is that you shouldn’t ever be able to let tasks starve for weeks in the first place. But maybe the total days neglect metric suffices to ensure that… I’m eager to find out!