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?
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:
Infrastructure (mostly loose ends with the big upgrade now)
Lifecycle emails (part of new user onboarding, includes better unsubscribe controls)
Better payment options (Stripe Checkout everywhere, ACH, Alipay, Paypal – Stripe makes some of those easy)
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.
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:
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.
