Ideas for the Beeminder + Commits.to integration

We have a couple proposals for Commits.to’s Beeminder integration in the spec. Here’s an extended list of ideas:

  1. Simple integration from the spec: +1 for each promise created
  2. Advanced idea from the spec: absolute success, send the actual scores to Beeminder
  3. Send a +1 for creation AND a +1 for completion
  4. Half a point for creation and half a point for completion?
  5. Something convoluted with fractional beeminding?
  6. Separate Beeminder graphs for promises created and promises completed?
  7. Beemind your score directly

@alys points out that #3 and #4 are the same but with different scale. I was thinking the metric is a little more meaningful if you’re ultimately counting completed promises but created ones half count.

And maybe #6 is interesting in that you can vaguely enforce a commits.to score by adjusting the relative rates.

I didn’t think #7 would work because you don’t have an immediate action you can take to dispatch a beemergency. Like if it’s “I need to make a promise (or complete a promise) by midnight” that’s fine but “I need to get my score up by 0.00234” – you don’t know what it will take to do that.

But @alys to the rescue again! I shall try to capture what she said in Slack. Start a goal with your current Commits.to score and a flat slope, so if your score drops, you derail. There’d be no direct pressure to improve your score (which at this point she pointed out is ideal for those with perfect scores, as I see she still has) but once your score increased, even if the road didn’t change, it would be risky to be late on another promise because it’s hard to work out exactly how much the score would drop by. She cleverly cites Trivial Inconveniences here. As in, maybe it’s easier to just fulfill your dang promise on time than work out how late you can get away with being. You could also use autoratchet (aka the Max Safe Days feature).

Of course step 1 is to just do the simplest possible thing, probably #1! (I’m still doing #2 but totally manually, which is getting to be a pain…)

2 Likes

I do love your writings. :laughing:

That actually crystalised something that’s been in my mind for a while now. Keeping a perfect score is vital to me so commits.to is a great motivator but one that I use very conservatively, so much so that I haven’t made any commitments for weeks (laziness also plays a part here). Thus #1 is the ideal integration for me at the moment, and fortunately is easy to do manually (my new commitments goal).

3 Likes
  1. Use the API to allow a pledge for each commitment

Pasted lazily from my Slack messages:

Hook commits to up to the Beeminder API and make is so that you can make a commits.to and check off a “pledge” amount that you’ll pay to Beeminder if your commit doesn’t get done by the deadline.

marydoesntexist.comits.to/give_d_the_draft_by_thursday_or_40

marydoesntexist.comits.to/give_d_the_draft_by_thursday_or_40sting
(for less ambiguity, so that “to_decide_between_30_and_40” doesn’t result in a pledge)

GTBee without iOS
I’d use the shit out of that.

I probably would only use it for tasks with a sting and not all of my “will” statements, but I’d still use the shit out of it.

Maybe hook it into Todoist and Zapier so that when I drag a task into a “Commits” Todoist project, it’d create a link to the commit that included the task name, and the due date so that I could just add the pledge before dragging and then auto-post the commit to slack.

That’d only take me 45 seconds to create, but it’d be pretty useful.
(My connection through Zapier, I mean… not the link to Beeminder’s API)

3 Likes