I’m with @dreev in not wanting that feature unless the math works. Also, I don’t like the constraint of only being able to use a certain feature once a week—on certain goals I consider high priority, I might set an aggressive schedule so that every single day of the week ends up being an eep day. (Or I might just be lazy on an easy goal and get the same effect.)
I think the correct solution to the problem is the one I described: allow the ping interval to be changed and record that as part of the ping data. E.g. instead of,
1530711663 foo bar [2018.07.04 09:41:03 Wed]
1530712647 foo baz [2018.07.04 09:57:27 Wed]
1530715414 qux bar [2018.07.04 10:43:34 Wed]
You’d have additional metadata indicating what average interval time in minutes was used to calculate that ping time, e.g.:
1530711663 foo bar [2018.07.04 09:41:03 Wed] @45
1530712647 foo baz [2018.07.04 09:57:27 Wed] @15
1530715414 qux bar [2018.07.04 10:43:34 Wed] @120
It’s safe to change the ping interval as often as you want and to any length of time you want as the poisson process is progress-free. That is, no matter how much time you spend waiting for a ping on one interval (say 45 minutes), you haven’t made any progress towards achieving it. If you haven’t made any progress, you also don’t lose any progress by changing the ping interval.
I think the challenge here is not the math but the tooling. It’s very easy to get data out of the current TagTime file if you assume all pings have the same average interval, e.g. you can just grep for the tags you want, count lines, and multiply by 45 to get the amount of time you worked. All the current tools are built around that assumption, and so changing it breaks everything.
On the other hand, extracting a minutes parameter from each line and using it in calculations doesn’t seem particularly hard to me. The new algorithm becomes: grep for the tags you want, extract the
@minutes parameters, and sum them.
So I think it’s up to people whether or not they want more control over their variance. I think I’d probably use that feature in two ways: to reduce variance for certain tasks on their eep days, and to decrease the typical number of pings (increasing the variance) all the rest of the time when getting pinged is a bit bothersome (but I definitely still want the data, which is why I put up with answering pings now).
 But it does introduce the side effect that you’ll be spending more or less time answering pings depending on whether you’ve, respectively, increased or decreased the ping frequency. If your goal is very careful experimentation, it would probably be desirable not to mess with that parameter. OTOH, allowing users to mess with the ping frequency parameter would increase the amount of information contained in the log, which could maybe be used to correlate with something.