Ok, so I have this goal. I derailed, got 7 days respite and ratcheted to 2. Then, I entered today’s datapoint of -10 (the rules I have for this goal are complicated, and it is actually possible to have negative values – though it’s extremely rare – and there’s a value entered once per day). And suddenly I’m in red and about to derail today.
What is going on here? Two days buffer, rate 50/day, I enter -10, I should have 1 day buffer, no? If I had known, I wouldn’t reduce my buffer to 2 days, or I’d put in work to have at least 0 points today (not possible anymore because my rules).
This seriously makes me rethink my beeminding strategy of having at least some goals with positive pledges. I might just reduce all my pledges to $0 so that there’s still danger of derailing like this, but at least no unexpected paying. This, however, might make Beeminder a bit less effective for me…
I think the issue is that respite gives you horizontal buffer, while adding a negative data point reduces vertical buffer. So even though you had two days of buffer, you were right on the line, since the buffer was in the form of a break. So adding a negative data point immediately put you under the line.
It’s definitely frustrating when things interact in a way you don’t expect.
Sentences 2 and 3 of the email that everyone gets when they derail:
“Reply to this email letting us know what happened if this derailment was not legit! We’re extra keen to hear about anything that was confusing or seemed weird, even if the derailment was legit.”
Do you think there is space between “this complicated goal that I set up didn’t work like I thought it would in this unusual combination, whether because of a bug or my understanding or something”
and “I’m never using nonzero pledges again and I realize that Beeminder will be less useful to me now?”
One idea I had would be to email support and say “I didn’t realize this would happen when I recently ratcheted, could you unratchet me?”. I do not do much support at all, so this is from a “fellow user” perspective rather than a workerbee perspective, but it seems to be a reasonable question, at least!
Yeah, I figured that. That doesn’t make things any better, though – it just means that the “respite” after derailing is not a real buffer, but a false reassurance…
Well, I’d reframe this… The “I’m never using nonzero pledges again and I realize that Beeminder will be less useful to me now?” was precisely the thing in space between “this complicated goal that I set up didn’t work like I thought it would in this unusual combination, whether because of a bug or my understanding or something” and “I’m ragequitting Beeminder now”…
The problem (as in “my subjective reaction”) is made much worse by the fact that this is the second time when Beeminder behaved very unexpectedly after derailing (and that was a completely unrelated issue!)…
It’s not that I have a problem with paying $5 – I don’t (unless it’s every day, which of course it’s not). I have a problem with Beeminder telling me “you’re safe” when in fact I’m not.
Again, sorry for my anger (also, I edited the initial post to make it sound less negative, after dreeves asked me to…), I’m better now, but the disappointment is still there…
So, to unpick this a bit for my feedback spreadsheet… do I understand correctly that your feeling here is that describing a period of time with a rate of 0 as “safety buffer” is misleading, because it only gives you a rate of 0, it doesn’t stop you being on the wrong side of the red line?
In that case, one solution would be for us to tweak the wording on respite so it’s a bit more precise. Right now, it says this: “Post-derail respite (formerly “days of mercy”) is how much safety buffer you automatically get after derailing.”
This is literally true, that’s exactly what it does, but it doesn’t make it clear that that’s limited and the safety buffer you get is only a rate of 0, not “you can do whatever you like and we won’t charge you”.
Do you have any thoughts on how you’d expect it to be phrased? Here’s my attempt:
Post-derail respite (formerly “days of mercy”) gives you a period of time where you don’t need to make progress on your goal by setting the rate to 0 for that number of days. You can still derail if you add data that puts you on the wrong side of the bright red line.
Would that resolve the issue here? Or is it more that the graph can say you’re safe for X days and then that’s not true? The latter would be a bit trickier to solve, since your days of safety have always been just about where your data is relative to the line – it’s not an issue unique to post-derailment behaviour: if you’ve used this goal in this way before by adding negative data, you’ll have seen that happen before (though of course you may not have remembered that).
Anyway, it’d be useful to figure out what the actual improvement we can make here is, from your perspective!
Support Czar confirmation that this is something we would gladly do! We don’t want to charge you when something happened because you didn’t realise how X and Y features would interact, or something like that.
Though I realize this isn’t likely something that can be done any time soon, I wonder if “true breaks” would solve this, since it would mean you literally couldn’t derail during a respite period.
Would allowing users to set “maximum daily fluctuation” on any goal fix this as well? The issue here was that Beeminder didn’t know that the graph could move in two directions, so there was both respite/buffer needed in the x- and y-directions. As I understand it, maximum daily fluctuation is responsible for configuring the amount of y-buffer a goal gets after derailing?
Or maybe a goal with complicated rules such as this one, should’ve just been made as a weight goal in the first place, thus getting the y-buffer on derail for free?
