Doing some theorycrafting before I put this into practice…
Say I have a goal to, eg, cook dinner more frequently which is working well at 6 days per week, and now I want to add a new goal to start cooking earlier in the day each time, by 6pm, say. It’s easy to track “Yes” days where that target is also hit, but (1) what should the goal rate be, and (2) how to handle the 7th day each week where I don’t even plan to cook?
I think there are a few different ways to do this consistently.
A. Set the rate to 6/week and treat non-cooking days like a default zero for the day. This has the problem that missing a day of cooking at all causes a “cascading” failure and both goals derail.
B. Instead, fold the two goals together into a single conjunction of “did cook and started by 6pm” with the rate being 6/week. This loses the benefit of being able to miss them separately, so that crossing the time-threshold lets you “fail with abandon” — ie, there’s no longer any in-system reason to cook late like there is with two separate goals.
C. (With two goals again.) Let the deadline goal have a rate of 7/week and count non-cooking days as successes anyway. This is like the literal answer to the question “Was every time you cooked dinner today on time?” — if you didn’t cook, it’s the empty set, so the answer is still yes. This is a slightly awkward framing… But the real problem for me is that it no longer associates each (positive) datapoint with an instance of cooking. If I was entering data manually, I’d have to remember to enter that implicit success apropos of nothing.
D. Reframe the deadline into the negative “times I missed the deadline” and use a do-less goal, so the default answer is zero and each (bad) “yes = 1” entry is tied to a real instance of too-late cooking. And cooking on time can also add an associated datapoint here (a “no = 0”). This is the best answer I’ve got; I just prefer do-more goals as easier to reason about and find the mental “negation flipping” a trivial inconvenience.
(For simplicity, by the way, I’ve ignored when you might want to set the deadline goal to less than the main goal, like if you want to start at three days of cooking on time instead of the full six. This wrinkle doesn’t really change the above, but is most apparent in D — you would set the do-less rate to 3/week for three allowed-late days, instead of 0.)
I’d love to hear your thoughts on this!
I have the lingering feeling that there’s a clever solution I’m not seeing; like using negative datapoints in a do-more goal somehow… At any rate, how have you disambiguated between a miss and not-doing-something-but-it’s-okay in your praxis?
Postscript: As & after I wrote this, the general pattern became clearer… but I’m not sure I can explain it well, yet (growth mindset).
Some goals can be seen as “contingent” on another. A broader possible solution E is that instead of predicating every goal on the days of the calendar, it could be predicated on the datapoints of another goal. (What do I mean by “predicated on X”? I’m imagining a function from the set X to the values given — so the discrete x-axis is made of X’s datapoints.) Which resolves the non-cooking-day dilemma by having/needing nothing mapped from the empty day.
By breaking the fundamental day-to-number mapping, this would allow for such goal-multiplexes as: minimum-duration work-sessions (main goal: 2 sessions per day; contingent goal: 3 hours per session), simpler fractional-adherence deadline goals (main goal: cook 6 days per week; contingent goal: meet 6pm deadline 0.5 times per cooking session), and tracking your meditation practice in a somewhat complicated way (main goal: 5 sessions per week; cont. goal no1: 20min threshold per session; cont. goal no1: 75% estimated focus per session). There’s a whole world of possibility here for anything contingent on a non-once-daily action — especially if you’re just checking a boolean attribute, like threshold-surpassing or meal-contains-gluten.
This is obviously beyond the scope of core beeminder, but a system built on these grounds could cash out to C, above, while handling the empty-set-reasoning behind the scenes. Probably ideal for the way I think about these things, with the small downside of much greater complexity under the hood.