We have a couple proposals for Commits.to’s Beeminder integration in the spec. Here’s an extended list of ideas:
- Simple integration from the spec: +1 for each promise created
- Advanced idea from the spec: absolute success, send the actual scores to Beeminder
- Send a +1 for creation AND a +1 for completion
- Half a point for creation and half a point for completion?
- Something convoluted with fractional beeminding?
- Separate Beeminder graphs for promises created and promises completed?
- 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…)