Meta-feature request: can we see what Beeminder devs are working on?

I think submitting feature requests and bug reports would be less frustrating if we could get some visibility into whatever issue tracking system you’re using internally, so we could tell how issues have been prioritized, when they’re being worked on, etc.

If there’s too much garbage or private information to make it directly accessible, maybe just publish a weekly list of what’s being worked on to the blog or something? Like @beemuvi on Twitter, but when you start working on something rather than when you finish. Though it would be nice to see some sort of a backlog rather than just the current iteration (in agile terms… I have no idea what software development methodology you’re using, if any).

If this already exists somewhere, could you point me towards it?


It all tends to be a bit mysterious.

Occasionally @dreev will post a forum post about all the big things they’re committing to in the next [time period]

The ‘daily’ beemail (under reminders) often discusses some of what is going on at the moment.

There is a Trello board at:, but that tends not be used as much as you would hope.

The dev slack chat (accessible to Beemium users) is where the day-to-day action happens.

When the User Visible Improvements Goal is in the red it tends to inspire searching the forum for easy to make improvements.

But some kind of “what we’re working on page” would be nice, (or maybe if they started using trello a bit more…)


I thought it was Hipchat?

Get with the times daddy-o Hipchat is sooo 2015.

(It moved to Slack.)


Hah are you forgetting I’m the one who consumes the Beeminder IRC via a Slack bridge? They should advertise the room is on Slack to encourage people to want to pay for premium!


Thanks for the nudges, y’all! (Psst, the dev channel is now Slack and you can hang out there with us if you get a Beemium plan.)

We’ve tried so many issue trackers and to-do lists and things and there’s a fundamental, seemingly insurmountable issue with them. Namely, issues come in faster than we can dispatch them. Which means backlogs grow without bound and adding things to an issue tracker eventually means throwing them into an endless sea.

Unless you periodically declare to-do bankruptcy, which is a horrible solution. (I do have a bunch of thoughts on triage and beeminding total age of tasks and whatnot, but I guess that’s a rabbit hole for another thread.) Anyway, @apb did recently make a new Trello board with what we currently deem the Top Seven priorities. We might make that public (main reason not to is that it’s sometimes useful to talk about specific users’ graphs and things) but in the meantime I’ll list the current top priorities:

  1. Infrastructure (mostly loose ends with the big upgrade now)
  2. Lifecycle emails (part of new user onboarding, includes better unsubscribe controls)
  3. Better payment options (Stripe Checkout everywhere, ACH, Alipay, Paypal – Stripe makes some of those easy)
  4. Freebees Revamp
  5. Road Editor
  6. Analytics / Funnel analysis
  7. New and improved goal creation wizard

And then a long list of things that it pains us to not have be included in that list (the next autodata integration, callbacks so 3rd party integrations can be first-class citizens, premium plan revamp, uncle button, integeriness, etc etc).

But, as you’ve noticed, things are getting done – most recently the big infrastructure upgrade and the big dashboard experiment – so new things will move into the Top Seven and we definitely want to keep hearing what you think they should be.


Personally out of those I’m most interested in the road editor, and I think there’s a very easy way to get a “good enough” version of it: Feature request: delete “Take a break” entries

(Obviously infrastructure improvements should take priority over that if they threaten the stability / security / acceptable performance of the site.)

Re: endless backlogs vs. issue bankruptcy: I think endless backlogs are underrated. The issues you aren’t currently planning to do are still a place to record votes (by devs or users) and promote some of them. You do need to scrub them once in a while for things that have been made irrelevant (if A has been replaced by B, any improvements to A no longer apply).


IIRC when @dreev says “Road Editor” it also includes the change to editing the critical edge of the road rather than editing the centerline. You can already overwrite existing take-a-break entries (which is similar to deleting them), but today you can’t actually set a goal precisely without a spreadsheet to determine what the road slope will be.

So I think it isn’t just a better UI for today’s take-a-break, it’s going to let you actually directly control the goal rather than today’s action-at-a-distance model.


I don’t think you can overwrite take-a-break entries, or at least the way it works is extremely unintuitive. I just scheduled a “break*” that fully covered the period of my existing breaks, and it didn’t change my road at all as far as I can tell (even the hover dates confirm it doesn’t become effective until after the other “breaks”).

*Note that “break” is in scare quotes because these “breaks” are actually making my road harder, so if there’s some kind of minimum going on that could mess things up. I don’t think that’s what’s happening based on the hover text, though.

1 Like

Oh, I could see that being possible. Maybe @dreev can confirm?

That sounds like a bug! Can you point us to the graph in question? (

Extremely eager to make these issues moot with a proper road editor!

Needing to file a proper bug report, I eyeballed the graph (hard to do with no horizontal grid lines) and I think it did actually do something like what I asked, so I guess this is more of a usability problem. The Take a break section of this goal is pretty much incomprehensible; here’s a screenshot:

I would be seriously impressed if anyone can figure out what that’s supposed to mean.


As an aside, I’d love a blog post about what solutions you’ve tried and what works best.

1 Like

Broadly, that’s what Mark Forster advocates with his recent ‘no list’ suggestions. He’s critical of what he calls catch-all’ lists.

He does also suggest having master lists of ‘permissible projects’ and the like, in a similar spirit perhaps to David Allen’s higher altitudes in GTD. My current thinking is that the default place for new things is the ‘someday/maybe’ list, which can then get triaged during a review.