Using Beeminder to stay on top of GitHub pull requests?

Akrasia
1

I’m thinking about beeminding my GitHub code review requests to help stay on top of them. I plan to use the Beeminder API to update the goal. But I’m not sure the exact metric I should use. Options:

  1. Age of oldest PR where I’m requested
  2. Number of outstanding requests
  3. Something else?

I’m leaning toward option 1 currently.

Does anyone have experience with something like this? I know whittle-down goals are often used for things like this, but I’ve never liked whittle-down goals. And I’d also like to set it up such that it’s compatible with the autodialer.

1 Like
2

I usually annotate all my inboxes with both 1 and 2, but at this point that might be more habit than needing both.

1 Like
3

Heh. :slight_smile: My first thought on seeing the forum title (before seeing who wrote it) was that you could do some sort of automation (e.g., github email notification → ifttt → …) so that when a PR appears, you get an automatic TaskRatchet entry due 2(?) days later that tells you to both assess the PR and manually create a second TR entry to fully handle the PR by whatever date is appropriate. But maybe you’ve already thought of TaskRatchet. :smile:

This approach would allow for a highly variable / irregular number of incoming PRs, which is what would suit me (I get very few PRs), but if yours are more constant or at a more predictable rate… :woman_shrugging:

I’ve been having a lot of success with binary goals lately for “did I do…”, so if it were me I might start with “did I do an appropriate amount of work on PRs today” and see how that worked. It’s vague, but I know I can rely on my “not want to lie to Beeminder” feeling to make myself do an honest assessment. (And “appropriate” can mean “none” if the day is very busy for other, valid reasons.)

3 Likes