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!
Brainstorming:
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
not-very-thought-out thoughts:
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
have it?
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 [1] 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!)
[1] 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.
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).