# Whole Number Goals

#1

I wanted to track my discipline implementing one feature per week in my project.

When beeminder says that +0.15 due in a day, what do I do? I could simply put 0.15 and try to finish before deadline. Is there a better way to track and handle whole numbered goals like 1 per week?

#2

There are two pieces to this:

1. safety buffer

Beeminder assumes you are capable of making progress everyday. The easiest
way around this is to keep adequate safety buffer. If you want to do one
feature per week, start out with a week of safety buffer and a rate of
1/week, and it will say you donâ€™t have to make any progress for that first
week. When you do, you add a data point of 1, and then you have another
week to implement a feature.

1. â€śintegeryâ€ť

If you have premium (I am unsure of what level is required) you can set a
goal custom, and once itâ€™s custom, you can set it to be integery.
Intergery goals only accept data as whole numbers, but even when I set my
goals as intergery, I like to combine it with #1 above.

Do these sound like they could help?

#3

#4

@senthil, the even simpler answer is that when Beeminder says 0.15 is due but thereâ€™s no such thing as implementing a fraction of a feature, then what Beeminder really means is that thereâ€™s +1 due.

In other words, just mentally take the ceiling function of any numbers Beeminder is telling you.

(Itâ€™s definitely on our list to make that more normal-person-friendly, without needing to set fancy custom features!)

#5

Thank you everyone. I think, I understand it better now. I thought â€śsafe bufferâ€ť was for the first instance of the record. Didnâ€™t think, how it could be used effectively for a periodic integery type goal. I am going try it now.
I am also going to consider 0.15 requirement as 1 and that will keep me way above the buffer.

#6

I think that @senthilâ€™s response probably makes sense, but it feels worth noting that I explicitly do the opposite with m/blog. The fine print reads:

In order to advance to the next integer, I have to actually publish something. Other increments are just for selectively applying pressure.

So if I publish something, I get to go up to the next whole number, and if I do this before getting to .9, then that gives me a few days without Beeminder breathing down my back. But this way it keeps the pressure up so that Iâ€™m not just suddenly faced with â€śnow you must publish todayâ€ť.

I would only recommend this for things where it realistically takes several days to complete one integer unit of progress at good quality. And even then, you want to be really explicit about which goals youâ€™re doing it for.

#7

Ah, yes, fractional beeminding! We talk about that at the end of blog.beeminder.com/bucket and have some notes for a longer blog post about it which Iâ€™ll paste here:

I initially thought this was too slippery a slope, that without objective criteria for what fractional amount you could log youâ€™d gradually get weasellier and weasellier until you were entering a 0.99 for 30 seconds of work.

But I donâ€™t think itâ€™s as slippery as it sounds. If you try to slide down the slope you run into a wall: you keep putting in a fractional amount to eke on to the road but then soon enough the bare min is more than the fractional amount you have left. So then you have to actually finish the blog post or whatever thing youâ€™re beeminding.

The key is the rule that you canâ€™t get to the next integer without finishing the Thing. So you get some extra nudges with the fractional entries but you still have to hew to the overall rate.

Itâ€™s similar to having started with a longer initial flat spot, postponing the first real beemergency. In fact, the yellow brick road math says that if youâ€™re maximally weaselly about it then allowing fractional datapoints is equivalent to â€śpretend I started with one more day of initial flat spot than I really didâ€ť.

So, yeah, itâ€™s not a slippery slope you can slide down very far but the whole thing could easily become kind of pointless. Unless you could keep yourself honest with â€śIâ€™m entering a 0.1 because I truly estimate I did 10% of the Thingâ€ť. Maybe worth a try?

PS: Possible annoying thing about it: you could have a beemergency where your bare min is .2 but you only have .1 left to the next integer value. So now you have to finish the Thing and do 10% of a new Thing. (Again, â€śThingâ€ť is whatever unit youâ€™re beeminding.) But, assuming youâ€™re honest about the fractions, I guess thatâ€™s better than having to do a whole Thing on the eep day.

#8

Yeah, but itâ€™s worth noting that thereâ€™s no concept of fractional work in my m/blog goal. I donâ€™t have to do anything to increment the number. In fact, even if I publish a post the last possible day, I usually input

``````^ 0.1 "published http://malcolmocean.com/grow"
^ 0.2 "a couple days of break"
``````

so that the incoming pressure again feels serious.

This has worked quite well for me at times, although sometimes I do end up mostly writing things the last minute anyway, which I donâ€™t like. But I think that there are deeper issues here.

#9

Just to make sure: Does the graph end up accurately plotting the total number of blog posts?

Probably yes and in your example there the â€ś0.1â€ť was the amount needed to hit the next integer, which happens if and only if a new post is published. Is that right?

#10

Yes, exactly. If I were at say `56.7`, and I published something, I would enter `^ 0.3 "url"`.