I have a few Do Less goals that are “age of oldest”. These are usually “age of oldest FOOBAR in FROBNITZ inbox”, like “oldest item in Remember the Milk inbox” and “oldest email in gmail inbox”.
They really, really help me. On the other hand, I suspect there are some things on the Beeminder side that could help out even more.
I am pretty sure the “time until wrong lane” timers et al are incorrect, because they don’t understand that a datapoint pessimistically increases by 24 hours per day, but I don’t ride any of those edges so I don’t know for certain.
Does anyone else have goals like this? What sort of improvements could help out for age-based timey-wimey goals?
Mine are all script based, so I have a script that enters in the age of the oldest data point a few times a day. (It doesn’t do zeno polling.) I usually do it in hours.
this reminds me very strongly of a custom goal/reminder setup i helped a lovely user with awhile back (july 2015, where does the time go?!).
the ultimate goal was “keep a hard limit on my inbox age - no items older than X days in my inbox at any time.” like you, he had an autodata system set up to send that oldest value every day. it was essentially a flat whittle-down (do-less without autosum).
the key insight to coming up with a useful reminder system was that the hard cap and not the countdown is closer to the actual “time until derail” value you want to be paying attention to (if you’re tracking in days, which you probably should be b/c beeminder operates in days). so, for example, if your goal limit is “no items older than 7 days” and your oldest item today is 5 days, your hard cap = 2. in 2 days, your oldest item will be 7 days, and you’ll have to take action the next day to avoid derailing.
(then he set up a google apps script to label and color the beeminder reminder emails accordingly, based on the hard cap value in the subject line. this was quite a system. BUT the goal is still in use today, so it’s doing its job!)
so, ideas on the beeminder feature side of things: allow you to enter a daily default increase rate (vs. assuming one standard for all goals), then calculating the countdown off that could be a start!
radical alternative: ditch the countdown entirely for do-less goals, since it often doesn’t really make sense and causes confusion. the only rule is no more than the hard cap. you just get reminders every day telling you to stay under your hard cap.
it’s arguably useful in that it tells you “how long can i just ignore this thing before i derail, when i have the most defaultest goal configuration going,” but that is very counterintuitive and explained nowhere obvious that i can think of.
i was also going to say “and different reminders are triggered by the countdown time,” but i don’t think that’s strictly true for do-less anymore since the revamp (after that goal was created).
Oh do you mean if you use pessimistic presumptive? I always have that turned off so sometimes I forget about it. I mean I forget about the feature, not the goals, even though the feature is to help you not forget about the goals…
I think this goal type is one of the do less goals where countdowns could be accurate and useful :), but it’s working for me as is–I try to keep way under on these anyway.
Would anyone be willing to share their scripts for having age-based gmailzero? I would love to be able to handle my email via age instead of count. Thanks!
Everything about the Pessimistic Presumptive Data points has been surprising to me as part of my Do Less goal. The only thing I like about is that it gives the countdown time. I find it really convenient that I can look at all my goals in terms of how many days ahead I am - that’s much more useful and motivating than saying I am allowed 4.42 cheat meals today.
However the system can just do the math and tell me that directly in the same way it decides what initial limit corresponds to the 7 day starting buffer - if I have a limit of 6 and a slope of 3 per week, then I am 14 days ahead. The math works out the same as doing the calculation with PPR’s, but seems simpler to understand.
I don’t think this is true. I don’t believe Beeminder can infer anything about how much safety time you have because there’s no way for it to know how much things cost. For example, you could have a hard limit to 120 with a slope of 100 per week, but if the smallest thing you buy costs 200 then you need to wait another ~6 days before you can do anything.
@drtall, are you considering the potential of inspecting the historical data values when formulating this belief?
Which isn’t to ascribe any value of easy to this; folks beemind all manner of things according to idiosyncratic rules that are [some value of hard] to infer.
For some of my Do Less goals I have radically edited the point system but kept the same goal. This pollutes the QS value of the data and such an inference system would need to figure out how to detect the discontinuity.
Also, I don’t know how you could detect if the point system is:
+100 for awful thing that hasn't happened yet but might happen at any time```
So there's no record of the +100 thing in the historical data.
I have a DoLess goal for the beemind.me Trello card age service, but it doesn’t really work for me. The way it works, I’m not terribly interested in whittling it down, just keeping it under a limit (say 30), but Beeminder tells me that I either have +346 days, even if the current aging rate makes it eep! day the day after … the issue was discussed in the beemind.me thread, but I don’t think a solution came up then.
Works great, thank you! (and thanks for the clear instructions)
Is there a difference between readThreads and using the first-party gmailzero goal? (besides being able to run updates on your own schedule)
I think I found a bug…should line 106 not be using the negation operator? Seems to me like the polarity is reversed, unless I’m misunderstanding the intent.
So, can you tell I mostly use the oldest message functionality?
I think I was actually intending to beemind the unread thread count, not the read thread count–as the read thread count is what the official integration does.
I’ll take another look at this and make a new revision, but that’s the root cause.
It’s so cool!! I’ve gotten it set up now! Thanks again for sharing!
Naturally this means I now have a feature request… would it be possible to get a separate count for the oldest email with a particular tag or in a particular folder? There is a particular kind of email that I’d like to respond to with a faster turnaround and it’s those emails in particular where I’m most anxious not to let them get too old – I could adapt my email-flagging workflow to whatever is easier to code; right now I use tags.
I’ll take a look at that when I fix the whole unread/read confusion. Shouldn’t take long at all. However, if you have a Github account, could you request it there? It helps nag me better If not, nbd at all!
Thanks!
Thanks again for sharing!