I have a number of hypothetical goals with a similar structure that I haven’t created Beeminder goals for because I haven’t figured out a good way to represent them. They all have the following properties:
- There’s an existing backlog of items to do.
- New items can be added to the backlog.
- Stopping the addition of new items to the backlog is not part of the goal.
- Either that’s impossible, or is difficult / laggy / unpredictable, or I simply don’t want to decrease it.
- Corollary: new items added to the backlog should never make me derail faster than I would have a realistic chance to do anything about them.
- On any given day, some items are easier to do and some are harder or impossible.
- Any constant rate of addition to the backlog should not cause the size of the backlog to grow without limit, unless I derail.
- If the backlog is growing without limit, I need to do something to decrease how fast it’s growing (however difficult / laggy / unpredictable that may be), or change or abandon the goal.
EDIT: Whoops, clicked the post button too fast. Here’s the rest of what I meant to write:
I think “whittle down” goals are intended for this, but I don’t think they’re capable of respecting 2, 3, and 4. As I understood it, you would have to pick a fixed size that the backlog is supposed to maintain.
5 implies the number of items to do today should be a monotonic increasing function of the size of the backlog. 4 implies it shouldn’t be the whole backlog.
Here’s a way to do this in Beeminder, though it’s ugly:
- Every data point has a comment with the current size of the backlog.
- When the backlog increases in size, add a data point with a value of 0 to record the backlog change.
- When the backlog decreases in size by 1, add a data point with value 1 / log(previous backlog size).
- If the backlog decreases by more than 1 at a time, apply the same formula repeatedly (as if each were a separate data point).
- Goal rate can be, say, 1/day, which would mean if the backlog has size 10 today, I have to do 1 thing; if it has size 100, I have to do ~2 things.
One problem this does have is that it matters whether you record an increase or decrease to the backlog first. Another, bigger problem is that computing the data points is a pain in the butt. I’d really rather have each data point be the total size of the backlog and have Beeminder interpret increases and decreases in that value differently.
So far I’ve avoided trusting external API-using tools to implement Beeminder goal logic, since I’m worried about it breaking and derailing me (which is annoying even if Support will undo it), though I suppose maybe at some point I should reconsider that.