I think the biggest problem with commits.to is that a typical new user (even an eager beta user) will create an account, create one or two commitments, then forget all about it. Their score will asymptotically approach zero and then all their incentives are to never touch it again. The person is strictly worse off than before they created an account in the first place.
I propose we commit to addressing that before opening the beta!
Mandatory Beeminder integration! You can’t have a commits.to account without beeminding it.
If your score falls below 50% then your whole account is automatically deleted.
In combination with #1 or #2, automatic meta-commitments to keep making commitments.
Simply charge a serious amount of money for the service.
Thinking about point 2 makes me realise that some way of “resetting” your account (maybe just by deleting and recreating it) will be quite important to prevent people getting into the situation that they hate their commits.to score and never want to go near it again.
Once someone is invested in their score they’ll presumably never want to do this and lose their history, so it doesn’t ruin the incentive. But I can imagine it taking a few tries before people successfully integrate it into their habits.
As a user, I’m not very comfortable with it when sites try to make me
keep using them. But this does seem like a pretty likely problem. Some
Maybe a opt-out beeminder integration that’s out of the way enough
that people won’t disable it unless they specifically want to not
Deleting accounts that fall below 50% would make your first few
commitments pretty high stakes. In a sense they are already; if you
only use it briefly anything you do then has a disproportionate effect
on your score.
Maybe weight people’s scores toward the site average when they’re new?
This should accurately reflect reliability: if someone comes on the
site and fulfill one commitment, I don’t assume they’re perfect on
such a small sample size; I conclude that they’re slightly more
reliable than my prior.
A downside is that this makes the score more opaque.
@justyn, good points! I’d advocate for restrictions of some kind on the reset option, mainly because I don’t like the idea of falsifying your reliability score by starting over. Actually, this is slightly related to the idea future discounting.
@forrestwolf, also great points! And I agree about not being annoying about it. But with both Beeminder and Commits.to, committing is the point. So it could be part of the sign-up process to opt in to a commitment device for actually staying on the wagon. I want to do that for Beeminder itself too. Ideas at doc.beeminder.com/metamind which perhaps has a natural Commits.to analog in the form of meta-commitments.
I like the idea of an opt-in Beeminder integration. In the meantime, however, does anyone have good ideas on how to set up a manual Beeminder integration? I don’t mean “how” in a technical sense, I mean: what sort of Beeminder goal do you think would work well? What should the units be, etc.? I definitely need something to keep me accountable to looking at my commits.to so I don’t forget what’s there, but not sure off the top of my head what a good goal would be.
Right, I remember that from your blog post about it. I’m not sure if I want to do that, because it constrains you not only to finish commitments, but also to make a certain number of commitments in the first place. It is OK with me if I go a week without making any new commitments; I just want a way to make sure I don’t forget about the commitments I did make.
I see. Yeah, that’s important! And it makes sense to not want to commit to a rate of making new commitments. That’s even part of the original vision for this whole thing: to commit to logging every “I will” statement, with a goal of reducing the number of times you do that so that you only do it when you really, really mean it!
Fewer commitments is absolutely a win condition! (So @byorgey’s question remains open: what’s the right beemindable metric?)
Sort of related: I think a pretty key feature to implement (arguably another one without which we shouldn’t accept more beta users) is emailing the user every promise when it’s created. That could help with getting reminded because you could snooze the email or otherwise use it to remind yourself to do the thing.
More related: Did you notice we have an “add to Google Calendar” link? I haven’t been in the habit of clicking that but I think I shall now that I’ve reminded myself! It might also want to be more prominent somehow. Maybe being super in-your-face until you click it and then it transforms to something subtle. That might serve as pretty good inducement to calendar your commitments.
PS: I said my graph was manual but if I get in the habit of clicking the “add to Google Calendar” link then it will actually be semi-automated. That’s because I have an IFTTT applet that automatically sends every calendar entry to my commits.to Beeminder graph, initially with a 0 as the datapoint value. So when I have a commits.to beemergency I can change those zeros to my actual scores (and I have few enough calendar entries in general that it’s no big deal to also delete the entries that don’t correspond to commits.to commitments).
I do know there is an “add to Google Calendar” link, and I use it, and it’s better than nothing, but it’s not really a solution for me since I’m not in the habit of looking at my Google Calendar for todos; I just use it for my schedule (and what with teaching classes, meetings, students booking meeting slots, etc., I can easily have ~10 calendar entries per day, which makes a system to auto-log calendar entries a nonstarter for me). The email thing would actually be perfect for me since from there I could easily incorporate the items into my existing systems for tracking todos.
Another candidate solution to the meta-commitment problem: Charge a serious amount of money for it. (Let me quickly add that to the brainstorming list above and wikify it. [done])
Asking people to speculate on how much they’d pay for something is notoriously unhelpful  but let’s try anyway. What’s the most you might pay for commits.to? (Note: Poll is anonymous. We won’t shake you down if you admit to a high value!)
 It seems people are just horrible at introspecting about this and err enormously in both directions. Some want to avoid essentially voting for it to be more expensive than it needs to be, and others want to be encouraging or to feel generous or they think aspirationally about what they’d pay if they could. Consensus seems to be that those factors distort the answers so much that you might as well not even ask.
One option I can think of is to require a credit card on signup, and force the user to commit to some kind of payment scheme: either the beeminder approach where as long as you don’t fail commitments you don’t pay or the Journal Jerk method of charging you a lot, but less if you keep coming back to commits.to over the months.
For the first option, you could offer either the ability to charge yourself as you fail commitments by increasing degrees, or charge yourself when your reliability drops below a certain number, or if it stays there for too long, or some combination.
This seems a bit off topic to me, but I’d game to try to answer if I had a better feeling of what is offered.
Specifically, I think it would only be worth paying for if it comes with enough Chrome extension / Android app-ery to make it as close to 0 friction as possible. The product (in my mind) is all about this UX.
I’m not sure if this thread is still relevant because I haven’t yet seen anything anywhere else about your reliability score automatically decreasing over time but I’m a new user and haven’t read everything in detail yet so maybe I’ve just missed that. But anyway, some brief comments while I have them in mind which you can ignore if this feature no longer exists:
“Mandatory Beeminder integration! You can’t have a commits.to account without beeminding it.”
That might reduce uptake of commits.to but I don’t know if that matters, especially if commits.to never has a cost to use.
“If your score falls below 50% then your whole account is automatically deleted.”
This isn’t good for people who become sick or have a chronic illness that flairs up unexpectedly. If you’re relying on commits.to for tracking some medium- to long-term tasks, having them deleted would be unpleasant. I feel pretty strongly about this (comes from my Habitica background where we try hard to consider cases like this as an accessibility / fairness issue).
However I’d be in favour of a manual reset / delete option as justyn says, partially because anyone with a low score from unavoidable circumstances would be more motivated to keep doing their commitments now if the bad score could be wiped out. I agree though that that would need to be carefully balanced with the accountability aspect.
That does happen. You just have to refresh the page to see it. (And have overdue commitments, of course.) I’m super excited for this to happen in real time.
I almost view that as good. Even when out of beta, and from a pure business perspective, raising the bar for signing up can be worth it if it reduces attrition.
How about if we also sent you all your data before deleting you? Or just froze your account and made it read-only / archived. I do still want to figure out some way to prevent the common case that someone makes a few commitments and then forgets that Commits.to exists, or sticks their head in the sand and avoids it indefinitely.
I don’t like that idea. I really want the scores to stay meaningful. No take-backs or do-overs!
Good point! Makes sense. Better to spend your time on serious users.
I like that idea a lot! Maybe add a deletion step after a year(?) of being frozen.
Not as keen on that option although it’s certainly better than a plain delete. It wouldn’t help anyone whose email address had changed. It wouldn’t allow easy restarting, which I am guessing the freeze option would.
I would be in favour of forcing (or at least heavily pushing) Beeminder integration. People can then set a goal as conservatively as they like, but they would have long term reason to keep committing (they would be subject to the akrasia horizon, so would get the benefit of having to plan ahead and not listen to the temporary I-dunwanna feelings).
If there were some kind of “you must be active or your account will be deleted”, I think a vacation mode for things like gap years and long term illness would be good – even if it came with, say, a six-monthly checkin (with generous time to reply) to ensure the interest in coming back is still there.
I’m not answering your question, but let me point out that I didn’t use beeminder at all until I started paying for it. That kick of “well I paid for it so I’d better use it” is what got me started, then the akrasia horizon kept me using it.