I found this comment on the Trello Beeflat board:
user changed their rate and runits at the same time and wound up with their road getting all properly adjusted except for the final row. we submit runits change first and then rate iff runits is successful. it looks like maybe they gave a rate in terms of weekly rate-units, while also submitting a runits change from weekly → daily. so, this is technically user error, but broke in a bad way, and it is kind of ambiguous – maybe only ambiguous if you think about it too hard.
is there anything we can do to clear that ambiguity and rescue users from badly borking roads.
(With accompanying diagram that looks just like mine above.)
If I may object: I don’t think this is user error. There is no reason on earth to think that, if I want to go from 5 units a week to 1 unit a day, I can’t make that change directly: change 5 to 1 in the rate box, and change per week to per day in the units box, and then click Update.
I think it’s kind of crazy to expect users to understand how it works under the hood. “Okay, if I want to go from 5 a week to 1 a day, I first need to change the 5 to… let me calculate that… uh, 0.71 a day, so let’s put in 0.71 and click Update… okay, now let’s change to per day and click Update… okay, now I’ve MANUALLY CONVERTED MY EXISTING RATE IN MY OWN FUCKING HEAD AND WALKED BEEMINDER THROUGH IT STEP BY STEP. Now I can finally put 1 in for the daily rate.” (*) That’s… yeah.
What looks like at least part of the problem, to me, is that Beeminder is changing the road from the last time the road changed somewhere back in the past. In my last example above, that was September 16. So instead of changing my road rate starting a week from now, Beeminder changed it retroactively from September 16, aka six weeks ago. That seems like erroneous behavior.
I may totally be missing something (and probably am, because you guys are very smart cookies), but shouldn’t Beeminder be adding another row with a date seven days from today to close out the old rate and mark the start of the new one at the current akrasia horizon? EDIT: This was a display update misunderstanding; despite telling me the change succeeded and updating the final line rate in the road editor, BM didn’t actually update the display of the entire road editor. I didn’t see that until I revisited the goal from the dashboard. A new row was added to reflect a rate change starting at the akrasia horizon, but it uses the wrong rate. See my post below.
Judging by the before and after road editor screenshots above, the rate unit (runit) is an internal thing, but BM does remember that it used to be different (otherwise I’d expect the road editor to have updated all the old rates to be daily ones, but they’re still at their weekly values). EDIT: I just went into my goal again, some hours later, and now the road editor values have all updated to daily equivalents, aside from some extraneous added things that seem wrong (see my post below).
(*) This does appear to be what you have to do, however. After the snafus on the two test-case goals, I changed a third one piecewise. Starting from 3 per week, I changed to 0.6 per week (+) (so changed rate only) and Updated. I then changed to 0.6 per day (so changed runit only) and Updated. This worked to change the rate from 3 per week to 0.6 per day without derailing me or borking the road.
(+) This eliminates one step of my frustrated example in the main post; rather than go from 3 per week to the equivalent per day, then the desired daily rate, I can of course go straight to the desired rate, then change to daily units. (I know 3/wk != 0.6/day, but the goal was to get weekends off, so it’s really 3/5days = 0.6/day.)
on topology as an excellent thing to have a beeminder goal about (I just have a generic “maths” one).
or anything.)
)