But why do it now? Nothing. I'll do the first task where the risk of not doing something exceeds 50%.

ftfm.

God (by which I mean gods of this website) I wish I could edit my shameful English in the submission.

No need to involve supranatural authorities here: you can edit the project description by clicking the "Edit project" button in the sidebar.

So how would one start to determine these probabilities?

Well, I'll refer to example above.

Let's say I'm limited to four hours per day where I can be productive. We see that a paper takes six hours but it's also located right after exam. If Iwill study for test on the day before test and then take test on the day before the paper, Iwon't have time for a paper. The more hours of work I packed into that two day back-to-back season, the greater the probability is that the task which has the latest deadline will not get done.

This is a backbone of risk-minimizing algorithm I plan to use. It stands on the following principle: User can accurately predict how much it will take him to do a certain task; there will be no risks involved other than risk of running out of time.

But this is only true in a perfect world. For real world we'll have to analyze user's time estimate vs time spent. Something Joel Spolsky calls velocity.

It would also be kind of cool to base velocity from todo item titles. Let's say "packing a backpack" is a different type of activity from "preparing for a test" and should have different velocities from the database.

Here's what user will absolutely have to enter for this system to work though: - Title of todo item - Deadline - Expected hours - Actual hours

I'm not sure now if I, or anyone else, can be expected to enter as much as four items for every single todo item. what's more horrible is that user would actually have to understand how much time they spent on that fourth item.

But basically, it's FogBugz-style evidence-based system adopted for usual users which distinguishes between different types of tasks.

I'm not familiar with FogBugz, but let me see if I understand what you're saying.

Discarding probabilities for a moment, you have some amount of time in which to do work, and some tasks to accomplish during that time. The basic question is -- how should I allocate the time to accomplish these tasks?

The answer to this question, you suggest, is to minimize the risk of failing at one of those tasks.

I don't understand why risk is involved here -- why can't we just treat it as some amount of time in which to do a certain amount of work, without any sort of uncertainty?

Discarding probabilities for a moment, you have some amount of time in which to do work, and some tasks to accomplish during that time.

Yes. Yes.

The basic question is -- how should I allocate the time to accomplish these tasks?

No. The question is -- how to do everything timely? I presume you have the time to do everything but you don't know which task to do right now because you have so many of them.

I don't understand why risk is involved here -- why can't we just treat it as some amount of time in which to do a certain amount of work, without any sort of uncertainty?

We can't treat as some amount of time with some amount of tasks because: a) We usually don't know how long the task is going to take. b) We don't usually consider the fact that if we do each task right before its deadline we'll end up with a bunch of hard tasks near other.

We'll have something like this:

Monday: 2 hours on A + 6 hours on B + 4 hours on C + 2 hours on D Tuesday: 3 hours on E + 9 hours on F

The problem is that F will usually suffer the most damage and risks the most not being done or, most likely, not being done properly.

It is probably a good idea that not being done properly or can equal not being done. I want all the tasks to be done at a peak of mental productivity.

Also: we don't actually know that we'll spend 3 hours on E or 6 hours on B. (That's when velocity comes into play).

Hey mannicken. I also happen to have a heavy tendency to evolve twisted planning systems one after another. Up to now, though, I was kept back because I tried to build them with GUI bells&whistles, and always eventually gave up due to time constraints, so I could never do it exactly how I want it. In the last few days I decided to go the todo.txt way and built a set of scripts & accompanying todo.txt/log.txt format. More details here:

http://www.fsavard.com/flow/2009/03/plyn-yet-another-textfile-and-scripts-based-todo-system/

Of course it doesn't have your probabilistic model built in, but you could easily add it (provided you don't mind coding in Python) as a function of parameters in the todo.txt file. What I mean is: the basics are there.

As I said, personally, the GUI (be it Web (Rails) or other) held me back. With text files I can concentrate on the info itself, and it's soooo liberating. Next thing I'll add is repeat tasks.

So if you'd like to use this, you can send questions my way, no problem (the doc is probably not that clear).

i don't see why adding excess complexity to the problem (with probabilities) is a good way to start off!

probabilities are nice... but entering 4 fields will def. be a UI hurdle.

what you're basically trying to do is "prioritize" tasks "automagically" (once enough data is obatined)

but why not try this simple approach... http://www.youtube.com/watch?v=oTugjssqOT0

I'm working on a web version of this.. but classes are holding me back. maybe over summer..

You could totally do this with Remember The Milk as a backend.

Just indicate how much time a task would take in the notes or tags for each task. That combined with due dates would pretty much handle all your data saving already. And plus, you'd be able to edit your data through any client for RTM you wanted to, anywhere, including RTM's own site.