I have two goals that I converted to custom goals and changed their aggday setting well after their creation date. In both cases, this resulted in an immediate derail.
In the first instance, I called non-legit on the derail. In the second case, the goal had stakes of $0 so I let the derail go to raise the stakes to $5.
Should these derails be allowed? What if the system modified the road as if there had been a derail, but didn’t create a charge? In what case is changing aggday a legitimate cause for derail?
(Also, shamelessly stealing @phi’s idea of including a poll!)
- Aggday changes should never result in a derail charge.
- Not worth fixing. Calling non-legit is easy.
- The current behavior is correct. Aggday changes should result in people losing money.
I don’t know what allowed means here.
Is it a bad experience that you can change an aggday and it instantly derail you? Yes.
Should you be able to change any setting and get a surprise derail? Probably not?
Having any aggday just “work” on your goal would require more than just changing the road, I think. It would require changing the setting that tells Beeminder what side of the road you want to be on, for instance. What if you changed between max or min?
What if instead you could preview aggdays in the road editor? What if when you saved an aggday after previewing it, it warned you about details in the past? Probably bonkers idea: What if aggdays weren’t goal-wide, but instead had date ranges, and you could say “change the aggday from today moving forward”?
3 Likes
Hmm, good ideas… I especially like the preview/warning idea.
I thought about having aggday changes only go into affect from now onward, too. The problem I see with that is that the graph would no longer be telling a consistent story. What the line meant would change part way through.
I similarly don’t like how retroratcheting changes the goal in the
past, either. I’d love a way to keep a ghost line or something
showing the old roads, or at least a way to toggle ghosts on and off.
3 Likes
How does retroratcheting change a goal’s past? Doesn’t that only change the road from the present onward?
1 Like
Sorry, I meant road editing using the road editor, but … long story, actually 
1 Like
Yeah, I like the ghosts idea… 'cause, as much as I want my graphs to be accurate, the fact that the data changes half-way through a graph and it looks like everything you did before a certain date was a derail really isn’t accurate, either. So it seems like there must be a way to tell a more truthful story…
YBHP will do that.
In my view, no setting change should ever cause a derailment. If a setting change would cause a derailment, the user should be warned first: “this change will cause a derailment - please change something else first so that you can make this change without derailing.”
1 Like
I like this idea… But what would the user be able to do to prevent an aggday change from derailing them?
Well, for instance, say you were changing it from “sum” to “max.” You would have to add data so that the “max” values were sufficient to not derail.
1 Like
Yeah, that would work in some cases. Both times it’s bitten me are when I was switching form “sum” to “nonzero.” You couldn’t add any amount of data to prevent that from derailing—the road is just too high given that change in goal definition.
1 Like
Turning on cumulative might do it, if it was off before.
Cumulative was on for both before the change.
Yeah, in that case there’s nothing you could do other than add 500 fake data points at the very beginning or something. So beeminder should have an option for “this setting change will cause a derailment. Are you sure you want to make this change?”
Then maybe the legit check email could note that the derailment was in response to a settings change. Or maybe the default is not to charge for a derailment caused by a settings change, and beeminder still sends a email just to let you know.
2 Likes
Been thinking more about this, and it’s growing on me. I think it does the best job of preserving the graph’s truthfulness. The problem of “this portion of the graph means something different than that portion” could be somewhat alleviated by introducing another marker similar to the derail red triangle to indicate that a change has been made to the goal’s definition that changes how data points are aggregated going forward. Combine that with not derailing a user after a change to aggday, and I think you might have a reasonable solution…
As in, you could specify and change aggday for different date ranges?
Or, as in changing aggday only changes it for the future? Are you thinking once aggday were calculated for a day, it would be fixed?
Yeah, I’m thinking the latter: A change to aggday would only go into effect moving forward.