Continuing the discussion from How do I unfreeze a goal?:
1 Like
“Unless there’s a concrete reason for setting a goal date, you’re usually better off setting a target value and weekly rate.”
One concrete reason is that doing the latter results in very buggy and totally unexpected behaviour with retroratchetting and safe days, etc., I’m afraid. Usually the retroratchet just ignores the user-inputted values, changes them all, and then retroratchets with a rate that will be different before the akrasia deadline than it will be after you re-enter the values you originally had. I’d avoid using anything other than date and rate (for now) if you’re new and/or unexpectedness/bugginess will freak you out.
1 Like
That is a problem. Clearly not a straightforward one, because we’ve fixed and broken it multiple times. My view is that user-specified values are sacrosanct. When that results in something unexpected, we should address the confusion, not ‘fix’ any user-inputted values.
My favourite premium feature is auto-ratchet, which runs retro-ratchet for me every night. It used to push out my user-specified end date, which was unhelpful for, say, a goal about preparing for an upcoming conference. I thought we’d resolved that, but apparently not completely and consistently. Not least when there are scheduled breaks, an imminent goal date, inter alia.
General note: please let us know on support@beeminder.com when anything unexpected occurs. Even if it’s not strictly a bug, there’ll be something that we didn’t get right. They’re hard to notice because we humans are pretty good at working around quirks in any system and then forgetting that we’re working around something.
4 Likes
@bee and I, appreciating how bad this can be, recently went looking in the code for the place where we override the user input… and it’s a disaster. We didn’t have the confidence to fix it without risking breaking too much else. It can and must be done, of course, but I think it’s going to happen as part of the road editor.
2 Likes
This might be overcomplicated, but you could have it so that whichever value is X’d out is the one that gets changed after the retroratchet. That seems to make a lot of sense, it just might be hard to communicate to the user.
2 Likes
Seconded! The user has chosen which 2 road-dial fields to fill in. It is absolutely the correct behaviour to uphold those values and change the one that is X’d out.
Can it result in stupid roads? Yes. That’s a different problem. But letting the user specify exact values and then changing them is ridiculously wrong-headed.
Can it result in undefined/incalculable ratchets? Possibly. I’d argue that in such cases, not ratcheting is probably the correct behaviour.
Though if this weren’t a hard problem to fix in the general case, it’d be fixed already. Like @mary, I’ve mostly trained myself to work around it in how I specify my goals. Every time it bites, there is sadness.
Presumably this is hugely complicated by the current implementation of scheduled ‘breaks’. I’m expecting that the generalised road dial will enable true breaks-in-the-graph rather than temporary flat spots. (Not least because those get nuked by my auto-ratchet setting, and don’t function well for non-monotonic data or presumptively pessimistic do-less goals.)
3 Likes