Ignore what the goal is for, but notice the following things. A relatively flat road–this one is new, but once I have the goal where I want it, the road will be literally flat. Notice that the datapoints tend to increase 1 day per day, until I process the oldest item, and then it goes to zero or so.
I don’t really like them, but they make me keep inboxes moving and are basically essential to me not getting stuck on harder things and only processing easy things.
My issue: these goals get lost in the 65 other goals I have. Beeminder doesn’t realize that my goals are increasing at 1 day per day by default. If I have to make progress 4 days from now, Beeminder doesn’t know that, and thinks I have most of an infinity to dink around.
When this sort of issue happens, usually I am abusing Beeminder and need to ask for help.
I am ok solving this in many ways: restructuring my goal, writing a program to do things for me, waiting since a good solution is a few months away–basically anything except fix the part of my brain that most people have that allows them to have inboxes without ignoring the hard parts.
Apologies if this is something simple I’ve just missed.
Finding a way to handle inbox-type goals that “just works” is IMO probably the biggest improvement Beeminder could make to goal creation and editing. (I don’t have an answer either; I have the same question.)
So to me, this would work perfectly Beeminder understood that a particular goal would go over in a certain number of days.
How could we do that with what exists today?
I’m basically struggling that Beeminder assumes my progress doesn’t change if I don’t enter data.
What if I enter future datapoints? What if, when entering data, I enter in a datapoint for enough days that I enter a derailing datapoint? Can I derail in the future? Ah, I don’t think this actually solves anything
Could I made a negative slope, at rate of 1 day per day, and do something silly with the datapoint values, so a datapoint runs into the road in X days?
Ignoring your request to ignore, I notice that you mention YNAB so I wonder if it’s reasonable to assume there’s a new entry every day? If so, you could make this a Do More goal phrased as “Settle up YNAB” with some frequency. It ought to be the same as the Do Less goal here except when YNAB is idle / you didn’t buy anything.
Unfortunately I don’t have a suggestion for your more general question.
You do have the option of pessimistic presumptive reports, if you use a do-less goal.
Entering future datapoints works roughly as one would expect it to. They basically do nothing until the future becomes the present. You can’t derail in the future, but neither can future data prevent you from derailing now.
Here are properties I think would be useful for inbox-type goals:
the data point is the size of the inbox (weighted, if you want it to be)
if you are going to derail, you can always avoid it by taking action to shrink the inbox
in the short term, if the inbox grows, that can’t make you derail (you have no control over that)
in the medium to long term, if the inbox consistently grows too much, you should derail (you need to decrease the growth rate to make it sustainable)
if the inbox never grows, you should eventually be forced to empty the inbox
if the inbox is already empty, you shouldn’t have to do anything (even enter data)
no matter how high the size of the inbox, there is a maximum amount by which you can be required to decrease it to avoid derailing
Most of these properties could be provided by a sort of “reverse odometer” goal. Imagine an odometer goal where the values are always negative. (I actually kind of like looking at an inbox with 13 things in it as having a size of -13…) Now further imagine that any value that’s below (even more negative than) the existing value was handled as if it were a reset and re-anchor:
-12
-13
would be interpreted as
-12
0
13
0
-13
(which is a trick to get an odometer goal to restart at a different place). The goal needs to be cumulative, otherwise it isn’t possible to meet properties 2, 5, or 7 AFAICS. If it is, it meets properties 1, 2, 3, 5, and 7. The obvious way to get property 4 would be with a second goal with the same data, but I hate doing that. Property 6 is also tricky… the only obvious thing to do is feed the goal with fake datapoints:
Arg… it’s even harder than I thought. I think you might be able to get property 4 with some tweaking to the sequence of values used to do the re-anchor, but property 1 only holds in my proposed solution for the data you type in (but NOT for your graph) and I missed a couple more desirable properties:
within some range, if the inbox is larger, you have to clear more items to avoid derailing (equivalently, if the inbox is smaller, you can get away with doing fewer items without derailing)
some way of handling the fact that faced with the need to decrease an inbox of size 30 by 5, most people will pick the easiest 5, eventually resulting (assuming equal rates of inflow and completion) in the worst 25 items of all time sitting in the “I don’t have to do that, so I won’t” part of the inbox forever
I’m of the opinion that a single graph won’t solve my personal inbox problems.
I have had great success beeminding age of oldest item and number of work in progress items.
I have done a few inboxes where I only graph “total age”, where I sum up the age of each item with some sort of exponent, in order to make old things gross. It works ok as a singular metric, but it makes it tricky to know exactly how much I need to process. Because of that, my newer inboxes are split into multiple different graphs.
I am going to do something that is much more robotic than I normally can handle, as an experiment.
I’m going to set up one of these do-less oldest-item goals like this:
A do-more, where the datapoints are epoch seconds, representing the date of the oldest item. If the inbox is empty, I’ll enter the current datetime in epochseconds, and have a comment.
The rate will be 86,400 per day, offset from current epoch time by X, where X is my desired oldest inbox item age.
I’ll set the lanes to be 1 “day” wide.
Rate changing may be a nightmare, and I know now I wish there was a way to interpret epoch seconds as ISO8601. I will see what other robot snares there are there, and see if this is reasonable.
Don’t ever use rates, just change the total. Enter a comment on each datapoint with the ISO8601 date it represents. That should make it slightly more bearable.
For me, though, when I imagine Beeminding age of oldest item, I imagine myself in the moment saying “yeah, well screw you for setting that goal, past-Kenn. I’ll just derail.” That’s a really good sign that a goal wouldn’t work for me. Maybe it’s the all-or-nothingness aspect? I need to let that oldest item sit a while before I can muster the energy to either work on it or give up on it. (Plus giving up on things in general doesn’t really work for me… the idea keeps coming back, and if it isn’t already in my to-do list I put it there “so I don’t forget”. Is there any way to make a to-don’t list viable?)
I can definitely see oldest item goals not working for people, but excepting the “unexpected eep day” problem I sometimes have (which I can usually resolve in a few minutes, making it never really derail) it has worked well for me for a few years.
Note, I have oldest item inbox goals on inboxes where often the action needing to be done is file it away into my to do list as an action, or to delete it, or just read it. I don’t have this goal on anything where processing actually involves a lot of work.
Understood. I (ab)use my inboxes for tracking things where I’m waiting on someone else to do something (where if it’s been a really long time I might follow up with them, but most of the time it’s there there’s nothing to do about it). I’ll also leave something in an inbox if I’m having trouble deciding what to do about it (or whether to do anything at all). “Decide what to do about X” doesn’t work for me as a to do list item at all – not only do I not do it, it so thoroughly disgusts me that seeing it often makes entirely give up on doing anything from that to do list.
I have this up and running. It is working well so far.
I think that because of zenostuff , the line is not as straight as it should be, but this will be less obvious when the goal is older. (It may also be a bug, I need to audit this a bit.)
By rate change, I assume you mean changing the maximum age, e.g. from having 9 days to deal with something to having 8 days. With your old-style flattish roads, that’s nicely visual.
For these increase one-day-per-day graphs, I’d create a discontinuity in the road, leaving the slope constant but moving the road up or down.
Keep us updated, and please share code if shareable. Also, can I move this to Akrasia from InnerHex? Seems techie but not sensitive.
