(Not totally sure if this is a bug or if I’m just misreading something / have different intuitions than others. Also didn’t thoroughly check if this has been brought up before.)
When restarting a goal, I can set the “starting buffer” amount. (I believe the interface is the same for goal creation).
My expectation is that this means in 1 day (i.e. tomorrow), I’ll have to make progress on the goal, otherwise I will derail. In other words, my goal will be orange. But when I set this value to 1, my goal starts out blue. (I can then ratchet to 1 day of safety to make it orange.)
I think the rest of Beeminder is consistent with this understanding:
- An orange goal is “due in 1 day”
- Ratcheting so that the “number of safe days” is 1 makes a goal orange
If you decide today doesn’t count in “days until you have to make progress” then this would make sense, but I can’t make myself see that as a natural interpretation: if there are 0 days until I have to make progress, that means I have to make progress today, not tomorrow. “There is one full calendar day between right now and the day on which I need to make progress” seems clearly distinct from “There is one day until I have to make progress.”
Anyway! Perhaps my intuitions here are off and other people find this natural, or perhaps if it’s even a bit ambiguous it’s safer to give people an extra day (which they can ratchet away) than to leave them with one day less than expected (which they can’t immediately fix). I’m hesitant because this seems like a central enough feature that this behavior probably isn’t a mistake and might have some well-considered reason behind it.
2 Likes
Claude dug up this “roadstart” docs page for me (which contains a big red “DO NOT READ” warning, but seems relevant!).
This describes a hypothetical UI that seems clearer to me, asking the user to explicitly enter the date of the first beemergency.
The most relevant part is this:
We also have a hard constraint: Even if a user chooses “0.5 skuzzlewuppers per year”, if they don’t explicitly opt in to start with some initial safety buffer, they’re going to have a beemergency tomorrow of 0.0014 skuzzlewuppers due. They probably don’t want that but the UI has to make it clear to them what to do about that.
I can almost see how this gets you to the current functionality: if the default is “beemergency tomorrow,” then any extra buffer gets added to the one day of default buffer. (But I stand by my initial post, I don’t think this matches how “starting buffer” is described.)
1 Like
Thanks for sharing the confusion here! Just as an aside, I would recommend not basing anything too much on non-published blog posts that scrapers have discovered; sometimes they’re useful or seem like they should be useful, but sometimes they are way too old to be of use, and it’s not always going to be clear which is the case because they are not intended as user-facing documents.
Anyway, we recently started rolling out something that helps with this confusion on goal creation for some goal types:
It’s not quite setting the date the goal will start, but it at least makes it explicit what date the first thing will be due.
Sounds like it’d help to get that rolled out further and into goal restarts as well, though it doesn’t address the underlying confusion of “how many days should it be until the goal starts”. That sounds weird/wrong to me too… query, does the goal in question have a custom deadline?
3 Likes
