Backlog / inbox goals

Akrasia
1

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:

  1. There’s an existing backlog of items to do.
  2. New items can be added to the backlog.
  3. Stopping the addition of new items to the backlog is not part of the goal.
  4. Either that’s impossible, or is difficult / laggy / unpredictable, or I simply don’t want to decrease it.
  5. 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.
  6. On any given day, some items are easier to do and some are harder or impossible.
  7. Any constant rate of addition to the backlog should not cause the size of the backlog to grow without limit, unless I derail.
  8. 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.

Thoughts?

3 Likes
2

I’m not sure I understand your use case, but I can say that your calculation method will break if you ever manage to clear out the backlog entirely - you’ll end up trying to add a data point with value 1/0.

2 Likes
3

I have a somewhat similar set of goals, for a variety of inboxes. I have
done a few things.

  • “Age of oldest item in inbox”
  • “Number of items in inbox”
  • “Total age of items in inbox” (I have tried a variety of forms of this,
    including an exponential term so I prefer clearing old items)

I use goals like this for Pocket, Gmail, and Todoist. I’m not super happy
with them, but they work for me, so I’m not unhappy with them.

2 Likes
4

Good point. I haven’t actually used this yet. I’d probably hack around that problem by actually making it 1 / log(previous size of backlog + 1).

I’ve considered the first two of those. The first one doesn’t work well with 4 (maybe the oldest item just happens to be impossible to do today) and the second doesn’t agree with 3 at all. Total age or something like it is interesting, though. I don’t always have a timestamp, but perhaps I could add one in cases where I don’t.

One potential problem is strategic procrastination (“if I put this off a while, it will be worth way more points”) but maybe that’s not much of an issue in practice? And even if it is, you can just increase the goal rate to compensate?

1 Like
5

Yeah, they work well enough for me that fooling around with them more feels
like procrastination :slight_smile:

2 Likes
6

The absolute cheapest way to mind this is to manually enter the size of the backlog every day, on a goal that aggregates with nonzero. The added awareness of current size might be sufficient to get you to whittle it down, and the true datapoint values will let you graph your progress (outside of Beeminder) if that desire ever strikes.

Mark Forster suggests that #2 means it’s not really a backlog… so some of his other ideas on how to prune an ever-growing list of tasks might be useful.

2 Likes
7

I’m more and more drawn into the concept of beeminding input rather than output, so I would suggest using a “tasks done” metric rather than “size of backlog” one.

2 Likes