Take a break and then retroratchet

I took a break on one of my goals, duration is 1 week, to begin next monday.
Then I did retroratchet because it had to much buffer.
My break appears to have been canceled. Is this a bug?


Retroratchet doesn’t treat flat sections created by take a break differently than “normal” sections. It does whatever it has to to make you N days away from eep, including destroying your vacation if it has to.

Currently, I think Beeminder views this as WAI but there’s lots of feature requests around making breaks a first class thing that various parts of Beeminder would respect.


Hey @chrp! If you email support we can reinstate that break for you.

Retroratchet predates take-a-break; the current behaviour used to make more sense, back when you couldn’t schedule road changes. Now it causes confusion, so as @drtail says, this is yet another vote for implementing true breaks in the road.

PS: it’s particularly good for us to hear about stuff that surprises people, because that’s always a sign of a thing that needs more work. (Even when the behaviour is ‘perfectly right’, the affordances and expectations weren’t cued up properly…) Thanks.


@drtall What is WAI? I too am for making breaks a first class thing: I use them to schedules my holidays, which are fixed some time in advance.

@philip Thanks but I think I will leave it as it is. It will force me to build some buffer.


“Working As Intended” which is just to say they already know about the behavior and they’re treating modifications like feature requests and not bug reports. Maybe the term isn’t as widespread as I thought, sorry :slight_smile:


I had a similar issue. I set up several breaks for times when I would be out-of-town. The dates in Beeminder kept moving, and it took a couple of times of resetting my breaks before I connected the problem to using the retroratchet feature.

1 Like

note to self: don’t try to plan too far ahead. :slight_smile:

I think this is on the list of likely fixes this year, since the confusion/annoyance factor is rising as more folks start ratcheting their goals and other relatively advanced beeminding.


Just wanted rise this again/add another voice here. I feel pain pretty much each time I need to schedule a break :slightly_frowning_face:. The incompatibility with retroratchet is only one thing.
There is also the fact that I can’t really remove or edit the breaks I’ve added, which often leads to the total mess in the schedule when I try to “edit” things by adding additional overrides on top of previous ones. Also, the way the breaks are represented is not really easy to understand.


I rely on the visual road editor for breaks, which I don’t exactly find easy to use but does at least make it possible to modify breaks, and to check that I’ve set things up the way I intended before I pull the trigger. But it doesn’t solve the retroratchet problem.


You can actually remove and edit breaks if you get to grips with the manual road editor, or try the visual road editor as @oulfis suggested. :slight_smile: I think a lot of people think the road matrix is only modifiable by us, and it’s not true – you can edit it as well, as long as you don’t want to make the road easier within the akrasia horizon.

Re: the representation of breaks, what do you mean by that? When I put in a break using the break tool, it says there’ll be a rate of 0 from x-date to y-date – how do you think that could be clearer? Are we relying too much on people understanding graphs? (Because to me, a rate of 0 is obviously a flat line which obviously means no data will need to be added to be on the right side of the line, and also obviously means “a requirement of 0 per time period” – and I’m not much for thinking mathematically. So it’d be good to know where this is failing.)

1 Like

Well, one problem I always have, over and over again, is fencepost errors: I’m never sure whether the listed begin/end dates also have 0 rate. I’ve gotten burned by this – thinking my break was longer than it turned out to be, because the beginning/end date wasn’t actually set to 0.

1 Like

For people who put it in via the take a break function on the stop/pause tab, the flat spot begins on the first date (the from date) and ends on the second date (the to date). That seems logical and as expected to me?

The “upcoming breaks” wording could be confusing, I guess? E.g. here

" Upcoming changes:
Through 2018-11-09 increase at rate 5
Through 2018-11-17 continue at rate 0
Through 2029-04-18 increase at rate 5"

To me it’s obvious that means that “up to and including 9th November, the rate is 5/time period”, “up to and including 17th November, the rate is 0/time period (flat)” and then “up to and including 18th April 2029, the rate is 5/time period”. (Time period being whatever you’ve set, day/week/month/year.) Would that be clearer wording, maybe (with the system inserting the actual time period chosen not just saying time period)? :thinking:

What might also be confusing if you look at the road matrix is that the entries there aren’t “a new rate starts from this date”. Instead, they mean “this is the date when the stated rate ends”. So e.g. “end date 2018-12-10, end value [blank], rate (per time period) 5” means the rate of 5/time period ends on 10th December (and then the new rate starts on the following day).

1 Like

Graphic road editor is my savior. Didn’t know I can do that :stuck_out_tongue:

Regarding the break representation: I share the @lanthala confusion there.
I think the “From: date. To: date” format would be less confusing. If you can have a specialized graphic representation of upcoming breaks would be even better :slight_smile:

1 Like

If this is true (no reason to doubt it if you say so), I find it very confusing as well. I would expect any intervals to include the defined starting date.

At least in real life, when I hear someone say “No more smoking from January 1!” I would think that she would smoke her last cigarette no later than December 31. And “20 push-ups daily from tomorrow” includes doing 20 push-ups tomorrow.

I guess the cleanest solution would be [from : to] with both dates inclusive (so, the next “from” equals the last “to” + 1), but if only one date is given, I would always assume it to be inclusive.

1 Like

Honestly, I see no reason for an ordinary user to need to look at the road matrix; the “upcoming changes” should be informative enough, or even the road itself. The road matrix is what specifies the line of your yellow brick road on the graph, so I’m fairly sure it’d be difficult to change how it works (and, I could be wrong, but I think there’s little point in doing so since the primary use case is staff fixing your graph, and we understand it!).

If I’m wrong and there are people using the road matrix who think it’s confusing, then do let us know! There are other easier ways to check what your road is doing, and even edit your road, but if this is something people are using we might have to give it some thought!)

1 Like

Maybe I was getting a bit ahead of myself. I thought this applied to the regular (i.e. on the goal page) pause editor as well. :slight_smile: But it’s pretty clear in the Stop/Pause tab of the goal page with the “through” being inclusive.

You can view the road matrix on the goal page as well (under settings), but it’s buried enough that I definitely wouldn’t expect it to be the first port of call!