This works (and is how I do it), but I also get the idea of not having to think about it. So I can see the usefulness of the feature. Noted!
I interpret the data points as relative to the work you have to do that day, so for instance, if you don’t actually need to do work that day, a 1 data point accurately represents “did everything I needed to.”
You could auto-add a note saying “this data point auto-entered because this goal is weekends only” or something to make it more clear.
Dislike! See Beeminding things with unknown frequency
EDIT: failed to notice at first that @mary already made this point for me and i see your counterargument about accuracy. but even though you’re accurately measuring “days I did everything I needed to” that’s not as useful and interesting a graph as one showing “number of actual things I did” over time.
See, I find it a lot more useful to know whether I did what I needed to.
I think this is related to Team Yellow vs. Team Black:
Those of us on Team Black, like me, care about the logging system being most motivating, not the purity of the real-world nature of the graph. This way, the data you log is a function of both what you do and what you need to do, as opposed to just what you do.
What do you think is the best way to handle weekend-only goals?
Another possibility is to allow for uploading a list of numbers used to shape your future road - that way you could script something that would create a table to auto-modify your road for weekend-only the way @apolyton does manually.
Here’s another example:
If you don’t mind running some cron jobs on your laptop, you can use Beelint: Another take on weekends-off & vacations to automate a goal which eeps whenever your weekend-only (or weekday-only, or whatever you want, including collision with Google Calendar events) goal has its eep on an invalid day. It’s janky but it’s the only solution I’m aware of.
I thought of another option:
- Just put it in the fine print that the goal is weekends only, and set it to the daily rate you want for weekends. Then report all weekday derailments as non-legit.
This way you’re in the red on weekends, don’t have to enter any other data, and don’t have to change your road. And it’s fully QS-first compliant! You can even automate the “non-legit weekday derailment” email to beeminder!
The part where this makes the Beeminder folks miserable proportional to the utility of their missing features is appealing in a sadistic way, but I worry that it robs Beeminder of its primary elegance: the idea that creating a goal means I’ll do the thing. I mean it feels like you’re only cheating yourself ultimately.
Well it is shifting the effort to compensate for missing features to the staff, but they’re just performing the service we pay them for - it’s not that excruciating!
But from the beginning the goal was created to be a weekend-only goal. So you are doing the thing as originally specified.
That’s what the fine print is for - weekday derailments for such a goal are no different than any other derailment that’s not legit for reasons specified in the fine print. You’re doing what you committed to, and the rest is just a question of accounting.
So I don’t see it as cheating yourself.
Of course you’re right including the fine print, but I typically like to consider a goal just in terms of its Road Dial. I mean consider a goal where you set the Road Dial to 1 Thing per week and you say it’s weekend-only. You could derail every Monday without ever doing any of the Thing at all. In which case what’s the point?
Well you obviously need a goal that would derail on the weekends if you don’t do the Thing. Of course if you choose a vacuous example then there’s no point, but that’s because you chose a vacuous example lol.
As far as the Road Dial, just think of it as a daily rate that applies only to the relevant days. Like if it were 1/day, and the fine print said “not on my birthday,” then on the week of your birthday, the Road Dial would still be accurate on the applicable days.
Thank you for the suggestion! I think creating breaks from the web interface is quite easy, I just need to remember to do it at regular times (lets say once per month). The good part is that the graph will act as a reminder that it’s not as it is supposed to be.
I just realised that I have a “do less” goal which when “weekends off” is enabled allows me to enter a value for weekends.
@dreev is it possible to change an existing goal to the “do less” type?
I could set the “regular” rate to 0 and the weekend rate to my desired one.
Excuse me but this the entire problem statement. It can’t be done using Beeminder as it exists today unless you take very special care with how you enter data points relative to the road dial, you are sure to only change the slope of your road to be multiples of the frequency of your acceptable days, you only derail with safety buffer in such a multiple, you only retroratchet with correct choices, etc
I find your attitude quite peculiar
I’m sorry but I don’t understand; I must be missing something.
It’s just like any daily goal that derails when you don’t do the task. Just set it to no safety buffer and autoratchet to 0 - why wouldn’t it derail on the weekends?
I don’t understand what you mean about entering data points, slope of your road, etc.
Huh what? Why?
Sorry, maybe we’re just miscommunicating.
To take a step back, the fundamental things that I want from Beeminder is a guarantee that “When you set your Road Dials, you’ll be forced to do those things at those rates” and “If you have no eep-ing goals, you don’t need to do anything today.”. Beeminder bugs which negate these guarantees are the ones which frustrate me the most.
For example, you can actually exceed the rate you specify on a Do Less goal because Beeminder doesn’t actually enforce the limit it displays in the UI. So if you think “Ah, my Do Less goal says my limit today is X so if I do more than X I’ll derail” you are mistaken. (Details at Why don't I derail? ).
There’s also failures of the “bright line” principle, for example What do the colors actually mean? . This makes it harder to reason about whether you need to do more for your goals and therefore makes it more likely you derail for non-legit reasons.
Whenever you derail for a non-legit reason or fail to derail when you should, Beeminder has failed as a platform. I say this because you’re simultaneously not doing The Things you want to do and you’re also not being stung.
Now to come back to the topic at hand, a goal which can only be performed on specific days of the week is prone to non-legit derails. If you can only do it on Saturdays and you derail on a Saturday, that’s a sting and you deserve it. But if it derails on a Tuesday, it’s not legit. Sure you don’t lose money for the Tuesday derail, but you’re also not accomplishing the goal you set out to do.
So you have to make a choice: 1) be okay with Beeminder not actually forcing you to do The Things (in which case why am I using it at all?) or 2) do something to ensure that eep days only fall on legit days where you can actually do The Thing.
Suggestions of the form “You should look ahead in your calendar” miss the fact that the entire point of Beeminder is that it tells you what you need to do today. So if Beeminder can’t correctly determine that you need to do The Things today, then Beeminder is less useful than it could be.
My suggestion of automating this “beelint” goal such that it eeps whenever you need to do future work for a non-eeping goal is satisfactory because it maintains the principle that “If I have no eeps, I don’t need to do anything today”.
Thanks for the detailed clarification! Your beelint program looks awesome by the way.
If I understand it correctly, if your goal is due in 4 days but today is the only day of the week you’ve marked as acceptable, the beelint goal eeps with a comment telling you which goal you need to work on - is that right?
That’s definitely a valid approach, but I’d rather have the actual goal that needs attention eep, at the price of either suffering non-legit derailments or entering a 1 on weekdays representing “no need to do anything today.”
Seems like the ultimate ideal is to auto-modify the road, right?
Earlier I said
Seems silly, but I didn’t realize this could be done with the API! Wow the API is really powerful. Whatever happened to beevacay? You said
So you said
Agree very much on the second - the eep is a signal to do something and otherwise I won’t do anything.
As far as the first, it seems like you think of goals as being fundamentally only of the form “do X at rate Y” whereas I see a goal as a commitment contract that could potentially be much more complex.
Accordingly, I see non-legit derailments as part of the process - the world is complicated enough that there’s just no way all derailments are gonna be legit, and that’s why beeminder includes the human element. Otherwise we wouldn’t need to pay them, just write a script that transfers money from your account into a retirement account you never see or something.
So I want beeminder to enforce the commitment contract, not just the rate. My vision of beeminder is that you can put in a complex commitment contract and it will be enforced by the whole system, which includes humans checking if the derailment was legit.
I believe this bug was fixed a while back, wasn’t it? The colors now seem to correspond to number of days.
So as I indicated above, I don’t see non-legit derails as failure, because “doing the Thing you want to do” is more complex than just the rate and needs to be enforced by humans checking if the derailment was legit.
But as I said earlier, you are accomplishing the goal you set out to do, because what you set out to do was to do it on weekends. So Beeminder is forcing you to do what you set out to do, it just also includes some non-legit derails that you have to correct after the fact (and this can be automated as well)!
To clarify, if it tells you that you need to work on the goal today, but doesn’t tell you that you need to work on it until it says “6 days,” how’s that? Because my weekly suggestion does tell you that you need to do it on the correct day, but requires you to know how long to work on it.
Yes that’s exactly what it does.
I completely agree. I spent some time trying to figure that out and ultimately gave up. I agree with what you said conceptually ("…uploading a list of numbers used to shape your future road…") but in practice I kept running into problems trying to make it work. Perhaps it will be easier to do when the yellow brick halfplane is deployed? Or maybe somebody smarter than I am should try?
I’m worried we’re talking past each other here, so rather than repeat myself I’ll provide an example of the concern I have. And maybe you can tell me why my example is nonsense or why I’m wrong to worry about it?
Suppose you want to make a goal with the commitment contract “I will on average spend 3 hours in the gym every Saturday, but when I fail to do so I get two weeks off to recover mentally”. I think the most natural way to model this in Beeminder would be to set a rate of 3 per week and a derail mercy amount of 6.
Problems I will encounter include:
- If the goal eeps on a Tuesday and derails, I’ll get 6 hours of gym credit which means I don’t have to go on this coming Saturday even though according to my commitment contract I ought to. This is Beeminder failing to enforce the contract’s terms.
- If the goal eeps on a Saturday and I go spend 5 hours in the gym, the goal will now eep on a non-Saturday because 5 does not divide evenly into 3. So the situation above will come to fruition next week.
- If the goal is currently eeping on a Saturday and I retroratchet the goal, I have to take care to leave a safety buffer that is a multiple of 3 or I will end up with the goal eeping on a non-Saturday. Same thing with respect to the Take a Break feature.
My point being that Beeminder is ill-suited to enforcing the commitment contract I specified, even though I think it is a pretty simple one and not unreasonable. Does this make any sense?
Oh that would be great.
Oh hey, I just found out that someone made a Beescheduler that does this!
Makes total sense, and the way I was thinking of adapting it wouldn’t work because of the “two red days in a row” problem. Thanks for clarifying all this!
Does beelint recognize binary/nonzero goals? That is, if I have a binary goal that needs to be done twice a week, and have beelint do it weekends-only, will it notify me on Saturday or think I can do it twice on Sunday?
Looks like this is not true, actually
Yes, it has limited support for binary goals. Specifically, there’s a config option
always_valid_if_data_today which makes it so the goal cannot have a lint error if it already has a data point for the day.
For example, suppose you have a weekends-only goal that’s set to derail on Thursday. Today is Saturday so you can and should work on it. Beelint will complain about the goal until you put in a data point. If that shifts the eep day to Friday, then on Sunday you’ll get a new lint error when you wake up. If it shifted the eep day to Saturday you wouldn’t get a lint error (you can just wait until next Saturday to work on it).
The thing that it doesn’t do is detect a hopeless situation. For example, if the goal is configured as 0/1 per day and you set the rate to 3 per week, it’s impossible because there’s only two weekend days per week. Beelint won’t notice this and will allow you to derail the goal.
It is also very literal about “a data point” regardless of the value or aggday effects. An improvement would be to support a setting like “3 is the maximum value for each day” but that is not implemented currently.