On the commits.to Slack, @chrisbutler and I and others have been debating aspects of the dates-in-URLs question (should there be special syntax in the URL for the due date, what future features should URL syntax potentially support, how to extract the due date from the URL) and I wanted to try presenting what might count as the logical extreme of what I’ve been advocating…
I started writing this as a wild and crazy thought experiment but then @echodaniel chimed in to propose exactly this in all seriousness so I’m now I’m taking it more seriously myself…
What led me to considering such apostasy is that I’ve found I mostly prefer creating commitments without thinking about a due date. I just accept the one-week default. Which is usually a pretty bad default. I don’t bother to change it but I kind of want commits.to to make me change it.
So what if we brought back the notion of confirmed vs unconfirmed promises, with the UI treating initially created promises in a special way so that you had to or were incentivized to confirm their due date? Maybe we still keep the date parser so if a date is there and parsable in the URL we’ll use it to set the default for the date picker. But it’s not used as the due date unless you confirm it. Maybe until you confirm the due date it’s treated as due at promise creation, so it’s immediately the most urgent thing. And maybe we make it so that with no confirmed due date it stays the most urgent thing regardless. Maybe that’s enough to induce the user to pick a due date? Or for real inducement: if there are any unconfirmed/due-date-less promises we show the overall score as “N/A”.
I’m starting to think something like this makes sense. At least for the way I use commits.to. Eager to hear what others think.
Makes sense to me, but I think it’s still nice to have at least a basic date parser there for quickly specifying commitments with a specific known deadline. But if you have to confirm and you have an opportunity to set a due date later, it takes the pressure off of thinking about trying to support all the crazy date specification features you would want in the URL.
That’s really interesting. So I could create a promise and give it a due date, but with 5pm tomorrow default due date. I see that’s the default due date only if you omit the date from the URL. Would you consider adding a “maybe” operator or does that go against the spirit of committing?
Here’s what I’m thinking: 5pm the next business day is a great buffer to allow me to decide if my time-to-complete is reasonable. There are days where I really need to commit to do everything that is thrown at me, and I might be good or bad at estimating. It’s a good thing to cultivate awareness of “is this a SWAG or is it a real estimate?”
We like to use a “Scientific Wild-A** Guess” to avoid hemming and hawing too much about how long things are going to take when we don’t even really know exactly how much of what is in the thing, but too frequently it gets recorded as “the estimate” and as we learn more about how big the task is, there is never a point where the timing gets re-evaluated or checked against other commitments we had made (or have had to make since.)
That would probably turn out looking like a pretty poor delivery rate. But it might be objectively worse to send the commitment with no timing information at all, than to include an initial SWAG estimate and re-level after some time has passed.
I’m just getting started with commits.to, so take me with a grain of salt! I’ve barely used the system and only about 1/4 through reading the full spec.
I’m skeptical that commits.to should ever support such a complex feature  but collecting use cases would be a good first step in convincing me I’m wrong!
In the meantime, workaround idea: don’t commit to a deadline unless you know you can meet it. Instead, commit to picking a deadline. Ie, a meta-commitment. For me it’s all about my personal rule that every “I will” statement get logged and tracked. Like don’t ever say “I’ll have that prototype coded up in 6 months” if you don’t feel certain that that’s a true statement. 
 Echoing it to see if I understand: Create a commitment with an initial estimate of the time it can be completed by and with an interface for refining that estimate later.
Hah that’s a good argument though, how can you account for re-leveled estimates as a fraction of truthfulness when that varies depending on (how long it took to notice the estimate was way off • and just how far off was it now)?
(It still has to sum down to the total truthfulness of the corpus of “I will” statements in the account, or it just doesn’t belong in this app…)
I think the initial default of next business day to put a time on it is a good compromise without giving up too much ground.
So far I disagree with this. The default of next business day is for the deadline itself, not a meta-deadline to pick a deadline! (:
And I don’t understand the first question. Or the answer is that you don’t account for re-leveled estimates. Or you only account for them by having additional commitments but each individual commitment is scored according to its original deadline.
Well that sounds fine, but if I’ve got a list of bullet points that is 65 points long after a great meeting, and I’m just walking down the list, entering data and committing to all of the things that are fully formed ideas I think I can get “in this sprint,” so I can cross them off (and commit to revisit all the other important things that aren’t fully formed ideas, so I haven’t committed to yet). I can start by committing to the most important / easiest / [choice of superlative algorithm] first, and then coming back at the end setting deadlines to schedule them [optimistically/realistically]…
I might honestly have way too many things to schedule all at once, but still know that all of those things will have to get done.
Is it really a meaningful distinction that “next business day” is not a meta-deadline? If you are creating the deadline optimistically (I mean that a simple GET request will set a default deadline, and you are expected to update it to the correct deadline… that sounds optimistic, not like “I will get this done sooner than is honestly realistic”), I guess it is a meaningful thing, in that I can “build promises” and not instantiate them yet, by not sharing or clicking on them, to buy myself more time for things I know I’ll need to do.
But… the deadlines are fungible, right? I’d understand if you say no, but not everyone is in charge of setting their own priorities, and sometimes deadlines are more like part of a negotiation. If something more important comes along at the behest of my manager and I’ve already committed to do too much before that one needs to be done, with the understanding that prior to this I was at or over capacity already…
My manager is reasonable and I mean that I could sometimes trade a new commitment for an old one (and if I did something like this with commits.to, maybe it’s somewhat against the spirit, but the system doesn’t record me as less than 100% truthy, or any other technical penalty for making this change, as long as the original deadline was still in the future when it was extended, right… ?)
I think you’re wanting to expand the scope too far.
I feel strongly that deadlines are not fungible at all (except by taking the hit on the score, of course) and that changing a deadline is cheating. Until we implement the public changelog idea I think it should be honor system to log any changes to the deadline in the notes field with a justification that’s like “commits.to misparsed this” or “there was the following miscommunication” and never like “such-and-such caused a change of priorities”. The latter is part of what the reliability score is measuring.
For commitments that become altogether moot, there’s already an option to void them (never just delete them! i’m not sure that should be possible at all) which I think should require a justification in the public changelog as well.
I’m not sure that that use case should be supported by commits.to but the way I deal with it so far is just keep snoozing the deadline, but only because that was explicitly allowed in the original commitment.
I don’t know how I will use the system yet, but there is a high probability that it winds up getting integrated into whatever issue tracker I settle on using for my most important project.
I am currently in the process of building a Chrome extension to integrate Pivotal Tracker with Bitbucket PRs, to facilitate building PRs (and checking on build status checks, and rebasing and merging PRs) from issue topic branches, so yes, by all means, integrate/automate all the things. If I open a PR and it is associated with a Pivotal Tracker story card, and the build checks pass, I would probably want that to generate a commitment, and to make sure that it gets merged by the close of business tomorrow if the checks pass (or set a deadline at that time, if it changes and for some reason doesn’t pass CI anymore, or if it can’t be accepted by the customer for some reason.)
I would probably never use a three-layer integration cake but like I said, I don’t know how I will use the system yet that’s how I imagine using it in my pea brain though.
The implicit commitment here being, I will merge or reject all PRs within a day, or provide feedback on why they cannot be merged right now. These commitments are convertible to “merge before X date” after the feedback has been provided, or they can be voided if “wontfix.” I am leaving myself open to failing promises if some contributor does not pull their weight, and that sounds like a feature to me.
(Or, I can just let the PR wither on the vine until contributor clears up what they want, and then it makes enough sense to put it on the Roadmap, when that happens it seems like a promise could also reasonably be generated. The commitment is not a promise until it’s “on the roadmap.” With me?)
Please note I am not expanding scope, as none of this requires the existing system to change. 90% or more of the burden is on other systems that I am already using and would integrate somehow. The integration effort would seem to be fairly trivial.
I have a pretty strong preference for allowing dates in URLs. It’s valuable to me to specify the due date and time as I make the commitment, and putting it in the URL makes it as visible as the commitment itself (no need for someone to click through to see the date).
Also, it allows similar commitments to be made at different times. Since old commitments will remain in the system indefinitely, I expect to get conflicts where I’m promising something with the same words on different occasions. I’ve already run into one such case and needed to reword the commitment. Adding dates avoids this.
There’s some discussion about the uniqueness problem at https://github.com/commitsto/commits.to/wiki#parsing-dates-and-promise-uniqueness with a comment that the reason for a collision will be clear to the user (true!) and that they can easily fix it (also true), but my feeling is that for best usability you wouldn’t want to have to worry about issues like collisions when writing a commitment (just like if you were making a verbal promise to someone, you wouldn’t want to have to consider the wording you’d used for similar ones in the past).