I don’t see why. Beeminder is explicitly designed so that derails get checked manually and roads get edited appropriately if necessary. That’s part of the functionality of the service. Users are supposed to use Beeminder in a way that’s customized to their needs and that involves using fine print and support when necessary.
@drtall I agree that new features shouldn’t already start out with technical debts, so I share your sentiment. But the two features in question are already out there, so in my mind these can’t be seen as new anymore, but rather as to be improved features. And it’s also true that the burden is on beeminder to change this and figure out what actually is the reason. We do have some agency over them however in that we are customers that beeminder wants to have. So how could this agency be used? Answers to that question, in my mind, are the only way to facilitate change as a customer. It’s true, that we shouldn’t need to do anything, but it’s also true that the problem is here. So we either can do nothing and hope or we could think about what we can do, realistically, to change it. Not because we should need to, but because we want to. And I, for one, would love to use both features!
Which is why I tried to say that if, hypothetically, all of us would let all our goals derail on the weekends and let support make adjustments as needed might do the trick.
Are there people who want weekends off but aren’t currently doing that? If so, why aren’t they?
Using support like @zedmango suggests makes me uncomfortable (they’re such nice people; should we really be bothering them all the time as a backdoor to using a feature that the company as a whole hasn’t seen fit to fix yet?). On the other hand, the fact that it would make it abundantly clear how much benefit this fix would create for their community does make it tempting.
I think seeing it that way is a mistake. Part of the beeminder service is customizing your goals to your personal needs using the fine print; this is just a special case of that. So it’s not a backdoor to anything - it’s part of how the service should work.
I want weekends off for certain goals but I don’t use the feature because I don’t have a premium account. I also want certain weekdays off for other goals but the weekends off feature isn’t configurable or very generalizable.
I wrote Beelint for myself which is fully configurable and also examines your Google Calendar to find incompatible days (Beelint: Another take on weekends-off & vacations).
 The #1 thing that would get me to buy premium is autoratchet improvements, namely I want records of when autoratcheting happens and I want IFTTT triggers to fire when autoratcheting happens. I also want autoratchet to work with weekends off. TL;DR if weekends off were free I would use it as-is, but if I had premium I would actually rather use autoratchet since I’m forced to choose between them.
Sorry, by “doing that” I meant “putting it in the fine print.”
It’s kind of odd that the “weekdays off” thing requires a premium but the more general “non-legit derailment if your conditions aren’t met” doesn’t.
I’m stuck because I agree with both of you. I am persuaded, rationally, that we should use the service as @zedmango is describing. But the thought of actually doing it makes me uncomfortable.
Which of the following situations would make you uncomfortable calling non-legit, assuming that the fine print allowed it (setting aside the question of whether or not you’d actually want to put it in the fine print):
- it’s your birthday
- it’s a close friend or family member’s birthday
- a close friend or family member is unexpectedly in town
- a vacation planned ahead of time
- some type of holiday
- you’re sick
- you’re overworked with another job or project
It’s not about the situation’s nature, it’s about whether the situation is low frequency / rate limited or if it is potentially high frequency.
Everything you listed is relatively low frequency compared to 2/7ths of all days.
For example, if the fine print were “Odd numbered days off” then I would be interacting with support a lot.
So it’s the amount you might have to interact with support in a worst-case scenario?
What if you were interacting with support just as often but for different goals each time? That is, is it the amount per goal that feels like a problem (“I’ve bugged them enough on this goal”), or the total amount across all your goals?
I think it’s per goal and I think it is also a question of how foreseeable it is. If I say “I’ll contact support whenever I am sick or overworked” this is less foreseeable than “I’ll contact support on odd numbered days”.
To be clear I’m not arguing this is rational.
Because if it were foreseeable - what, you should have written a program to take care of it?
No, not exactly…
Like, on the two extreme ends, I feel like these resemble:
- “Hello, support, I’ve been struck by lightning and need help. I will contact you again just like this the next time I get struck by lightning which will probably be years from now”
- “Hello, support, today is May 1st and I need help. I will contact you again just like this on May 3rd and May 5th, May 7th, etc. forever”
These two just feel like different levels of imposition to me, even if they both derive logically from the same system (the fine print system).
The word “imposition” is interesting - do you see it as something outside of the ordinary use of the service? I’m assuming, for instance, you don’t feel that way about setting up goals or entering datapoints.
I’m thinking of the contrast with something like BAAS, where they explicitly agree to be in communication with you every day if that’s the amount you use the service.
Does it make a difference that your “imposition” would be in response to Beeminder’s emails asking if a derailment was legit, so you’re responding to their question rather than emailing them out of the blue?
And if you were a premium user would you feel more comfortable with the more frequent communication? Like you were paying for it rather than “freeloading”?
(thanks for entertaining all my inquiries here, by the way!)
I feel like support is part of the service Beeminder willingly provides in return for me voluntarily risking my cash. So, normally, I don’t feel bad about contacting support at all.
But, yeah, it feels like this is taking it to a whole new level, using support in a way that Beeminder didn’t intend, since they obviously intended that these (admittedly broken) features they built would do what we’re trying to do, not support.
I guess it feels like it’s outside the unstated bounds of the value-trade I have with Beeminder, which is subjective, I admit.
Hmm. But Beeminder’s whole philosophy is
don’t waste time building something until you know for certain you need to. How do you know? Simply when you can’t keep up with doing it manually, because enough people are actually using the shell of a thing you built.
I’m curious - say you worked a job where you had Mon and Tues off. How would you feel about putting “derailments on Mon and Tues don’t count” in the fine print then, since the feature doesn’t support that?
I think it hinges on the fact that it is a human-to-human interaction between me and somebody I know decently well. (I’ve enjoyed arguing with Danny about pointless things for enough years that you might call it friendship even though I only met him once. Not sure he feels the same way but the point is that I know it isn’t automated and I know who is doing the work.)
Edit: To be clear, Beeminder support has never refused to help me with anything or even grumbled about it. The mental hangup here is entirely generated on my side.
Reasons I wish retroratcheting (and by extension autoratcheting) moved the road up or down (based on yaw) instead of to the left:
- Retroratcheting wouldn’t move breaks, allowing for a goal with planned breaks to be retroratcheted.
- Retroratcheting wouldn’t mess up weekends off.
- The weekends off feature could schedule breaks to the end of the goal, instead of just the next weekend, making it possible to see what the current plan will result in.
As it is now, if you have weekends off, only the next weekend is scheduled, presumably to reduce the damage from autoratcheting. This results in an overly-optimistic value at the end of the road, since it doesn’t take into account all the weekend breaks that will be scheduled between the current weekend and the end of the road.
This is important to me because I’ve switched to explicitly using my contract time goals as my schedule when generating date-of-completion estimates for my clients. A road that overestimates the number of hours completed at the end of the road creates overly-optimistic estimates for my clients.
Because this swam to the top when I happened to be browsing the forum, and some stuff caught my eyes:
Spotted this and just wanted to clarify, as someone who works in support: we cannot do that. We can only make your road the same as if you didn’t derail if you have entered the data. If you derail and it’s not legit but you can’t enter the data, the closest we can get it (at present) is a no-mercy recommit, i.e. buffer of two days.
Here I’m speaking as me, not as an employee of Beeminder: that’s not how it always works, and it is not something you should expect, I think. Many teams actually use a method whereby they first create an “MVP”, a “minimum viable product”. You roll out the barest bones version of a feature rather than wait until you have everything perfect, so that you don’t invest any more time than you have to in a version that does not actually work for your customers. I don’t think that principle is explicitly in place at Beeminder, but I think it is implicit. [Someone links later to shirk-n-turk – exactly! Perhaps I should say it is explicit, then.]
Speaking as an employee of Beeminder: we rarely hear complaints about the implementation of weekends off, and if you’re interested in that feature changing, we do need to hear from you – as in this thread. We don’t necessarily know what’s working and what isn’t, even though we are all also users of the site, because even across the whole team, we don’t share all the specialised needs and use-cases of every user. Quite frankly, I had no idea that there was any perceived problem with this feature: it works great for me, and I’ve never run up against the incompatibility issue.
As long as it remains in your fine print. I’m not sure where you got the idea that there was a statute of limitations on your fine print or on support helping you, so as support czar (
whips out the correct hat and settles it on their head) I’d love to hear about why you thought we wouldn’t honour that. If there’s something in our docs that sounds kind of like that, I’d like to get the red pen out!
If lots of people took that solution, we’d probably take it as a sign to change how weekends off work to accommodate that way of using the site. Or we’d increase support capacity, or we’ll talk with people about personalised solutions, or whatever ends up being the right thing to do. That’s for us to worry about!
I work the same hours each and every day, regardless of weekends or most holidays, and other workerbees also pitch in on weekends and holidays as well. (By choice, before anyone worries about it!) Weekend derailments make no difference in that sense.