Task execution time limits

[ninewise]

A useful feature when you want to use Eva both for work and home tasks: adding time-limited cathegories to tasks. E.g:

• Tasks labeled "Work" should preferably be planned between 9am and 5pm on weekdays.
• Tasks labeled "Weekend" should be preferably be planned on saturdays and sundays...
• Tasks labeled "Morning" should be planned early, e.g. I like to go running in the morning.

Note how this is related to not doing any tasks when you're asleep: the default (unlabeled) prefered period could be 8am to 12am.

You might also assign a strictness to these prefered periods. After all, when the deadline is really close I might work in weekends. Or when I don't really have time in the morning, I don't mind running in the afternoon.

[Procrat]

That's an interesting take and shines new light on how I was thinking about implementing sleep thus far. Implementing a strict partitioning of your day/week seems like a reasonable and relatively easy thing to do. Relaxing that strictness sounds a bit hard for scheduling purposes. How would you go about it? If deadlines can't be met within a time segment, where do you cut? Sleep? Your morning ritual? Probably not?

Thank you for bringing this up; it's something I hadn't thought about like this. I changed the relevant roadmap item (46289571b2e969c5f5b1a413e507384da44e2d7d). Are you happy with that? Thoughts about implementation (or, dare I say it, a PR) are always welcome! :smile: (Although I have to warn you that at these early stages of Eva, I might be a bit strict.)

[ninewise]

I suppose the easiest method of relaxing the strictness is by assigning an importance/order to each segment as well. E.g. work > sleep > fun times. Then sleep could be cut for work, but never for fun times.

I'll have a look at your code before I start thinking about the code and a PR (you did dare say it) ;-)

[ninewise]

OK so I had a look at the scheduling algorithms, and I'll note down some ideas here because I need a place to put down some ideas and my cat is sleeping on my left leg so I can't get any paper.

• First though, to keep in line with the current Stijnish scheduling algorithm. I'd start by splitting the tasks per segment. For each segment, we run the same algorithm is is now run for all tasks (which I after a quick read comprehend as): repeatedly pick the least important item and schedule it as close as possible before the deadline, without displacing earlier schedule tasks. We panic if we can't schedule something before the deadline or after the current time. Next, we completely forget about this schedule except for the order in which the events are scheduled. Finally, we start filling up the actual segments with tasks in the previously determined order, each task in its segment. Now, we're in trouble if the tasks fit at first, but don't fit in segments. I'll think about it on my way to the train.

[ninewise]

Wow looking at the code again on the train, I noticed how I didn't read the Stijnish scheduling very well. I just read the first part and my brain filled in the remainder with Myrjalic scheduling.

[ninewise]

Idea one: I assume all segments are equally important, and the importance of the tasks will determine scheduling and possible segment flooding. We'd need to decide what importance actually means:

• I assume a tasks with lower importance will be discarded in case of conflict (lack of time) within the segment
• How much more important a task must be to flood a task in another segment. (Say, a 7 of work will drop a 4 of free time).

Idea two: Each segment has an dike height. So, say work is 2 heigh, sleep is 1 and free time is 1. A conflict in any segment could always be resolved by flooding to another, if there's a free spot. If there's not, a sleep task'd have to be at least 2 more important than a work task it's going to flood. A work task'd only have to be 1 more important than a free time task it'll flood.

This idea I believe has a lot of potential, but not really as a heuristic but more as a very complex backtracking algorithm. After all, you'd want to avoid too much flooding of the same segment, so you'd need to increase the dike of the (continuous?) segment each time you flood something in it.

---

Actually, because I think Eva users should rarily get in deadline trouble we shouldn't be thinking about segment flooding too much. I'm thinking we should just offer some suggestions to the user in case this happens and let him decide.

---

So, for an actual heuristic which is less creative and easier.

• For each segment, we check if all tasks can be planned. If not, drop or flood according to above or other rules or user interaction. If they can, use Myrjamic scheduling.
• ...
• Profit!

---

Idea three: more heuristic like. We need a segment modifiers again.

• For each segment (from most important to less):
  • Use Myrjamic scheduling to fill it. Skip but remember the least important task (with closest deadline) if it won't work out.
  • Add skipped tasks to the next segment, with their modifier decreased.
• Tasks left over in the last segment are panicked away.

---

Each of above ideas has a lot of problems. I'm slowly starting to get the impossible scope of this problem. Some thoughts about flooding segments only by extending them instead of at random crossed my mind, because segments might be location bound?

Sleep segment is approaching.

[Procrat]

Nice ideas! (Apologies for the late response. I have been working on the web UI.) I think it's a good idea to go with a minimal implementation first to get things going and enhance it later on. So I think that means strict segmentations.

Would you also make a non-labelled segmentation that both work and fun (and unlabelled) tasks can fill? Or would you require every task to be labelled?

[ninewise]

I think implementation-wise it'd be easiest to have a default label which would fall in the "remainder" segmentation. The remainder segmentation would be the least strict, so other tasks could easily overflow into it.

This and having an unlabelled segment would be equivalent in functionality (and even interface, if you just hide the "remainder" segment), I think. And for implementation it's the difference between using Maybe<Segment> or just Segment everywhere. (pun intended)

[Procrat]

You can now add, remove and edit time segments, and put tasks in their relevant time segment. There is also a default time segment from 9 to 5 every day. However, it is still an ordinary time segment, so the user still has the option to delete it or make it more specific. I only added the relevant interfaces for it in the web UI for now. The behaviour for the CLI did change however, in the sense that it won't schedule tasks overnight anymore. Hooray!