Display unscheduled tasks at the end of the milestone

[Ryan J Ollos]

Currently, unscheduled tasks have their start and due dates set to the current day. This is causing a bit of a problem for my group because it is not immediately obvious whether a tasks is unscheduled or actually has a start and due date set to today. We have many tasks that span a single day, so this issues arises quite a bit.

Although not a perfect solution, I think it would be less confusing to have tasks with no start and due date appear at the end of the milestone. It might also be useful to have them appear with some kind of marker, like the diamond that is displayed for a milestone, rather than the tasks having a span of 1 day.

Hoping to get some feedback and ideas about how to best deal with this.

[Chris Nelson]

This is really an ASAP (as soon as possible) vs. ALAP (as late as possible) dichotomy in scheduling. To handle this ticket in isolation, I'd add a schedule= option which took asap or alap as values and did what we do now or what you ask for. I think, though, that a better option is to wait a week or so for the better scheduler we're working on.

[Ryan J Ollos]

Replying to ChrisNelson:

I think, though, that a better option is to wait a week or so for the better scheduler we're working on.

Thanks, I will wait to see before working on any more patches. Is the scheduler going to be part of TracJsGanttPlugin, or is it a separate plugin?

[Chris Nelson]

Replying to rjollos:

Replying to ChrisNelson:

I think, though, that a better option is to wait a week or so for the better scheduler we're working on.

Thanks, I will wait to see before working on any more patches. Is the scheduler going to be part of TracJsGanttPlugin, or is it a separate plugin?

My vision -- likely not realized in the first release -- is to specify some interfaces for extension points that facilitate project management. The first two that come to mine are task scheduling and a resource calendar ("How many hours is Ryan available on August 8th?" "None" (he's on vacation)). I imagine those EPs will be in another plugin. The TracJSGantt would then 1) provide it's own, default implementation of the scheduling EP that does what it does now, 2) be able to find a more robust scheduler that is installed in the system. I have a scheduling plugin that provides a scheduling service and could be installed to beef up the Gantt's own simple scheduling.

[Chris Nelson]

I have ALAP scheduling working in my sandbox. I think I can extend this to ASAP fairly easily.

[Ryan J Ollos]

Replying to ChrisNelson:

I have ALAP scheduling working in my sandbox. I think I can extend this to ASAP fairly easily.

I'm ready and eager to test anything new you post ;)

[Chris Nelson]

(In [10688]) Refactor task sorting. Refs #9042, #8982.

• Comment sort routine. Minor white space fix.

• "sort" is really "compare".

• Sort all tickets in Gantt the same way we sort children of a parent.

• Don't need tempEnd if we have calc_finish

[Chris Nelson]

(In [10689]) Sort based on dependencies. Refs #9042, #8982.

This nicely puts milestones after their tasks.

This turned up a problem with dependency representation. When we did:

s = '1, 2, 3'
l = s.split(',')

l ended up being ['1', ' 2', ' 3'] so "'2' in l" was false.

So now we strip white space from pred and succ ticket IDs.

Also, Trac milestones don't have successors but an empty list simplifies other code.

[Chris Nelson]

(In [10690]) Schedule tasks by hour, not day. Refs #9042, #8982.

This is an first step toward handling dependencies (so, a four-hour task and an 12-hour task can take just two 8-hour days) but it also addresses a display but that tasks that took a multiple of 8 hours showed up a day too long in the Gantt.

Giving Trac milestones 0 estimates simplifies other code.

[Chris Nelson]

(In [10691]) Add as-late-as-possible scheduling algorithm. Refs #9042, #8982.

[Chris Nelson]

(In [10692]) Add as-soon-as-possible scheduling algorithm. Refs #9042, #8982.

ALAP with all starts changed to finish, successors change to predecessors, etc.

[Chris Nelson]

(In [10693]) Remove dead code (old scheduling algorithm). Refs #9042, #8982.

[Chris Nelson]

(In [10695]) Use adjusted estimate for computing hours, percent complete. Refs #9042, #8982.

• Add configurable default estimate for tasks.

• Add configurable overestimate padding. If work is already more than estimate, we likely need still more time.

• Improve reporting of percent complete. Use projected work, not estimate.

• Remove a stale comment; already fixed.

[anonymous]

This is somewhat experimental and not tested at all for tickets which have start dates specified. Feedback on functionality is welcome. I could use some code reviews, too. My Python is weak and I use recursion and object assignments in ways that may not be optimal.

[Chris Nelson]

(In [10696]) Fix a bug with tickets without due dates. Refs #9042, #8982.

[Chris Nelson]

(In [10710]) Fix several minor errors in commits for scheduling. Refs #9216, #9042, #8982. Applying a patch from rjollos. Thanks!

[Ryan J Ollos]

Okay, I'm up and running with r10710 on Trac 0.11.7 now. I think this ticket can be closed.

[Ryan J Ollos]

Replying to rjollos:

Okay, I'm up and running with r10710 on Trac 0.11.7 now. I think this ticket can be closed.

Sorry, I meant to post this note over on #9216. I'll do some evaluation of the new features for this ticket, and get back to you over the weekend.

[Chris Nelson]

(In [10809]) Fix conversion of estimate to work hours. Refs #9042.

When scheduling was converted from days to hours, one conversion wasn't addressed.

There are two factors that apply:

• Time per estimate (how many scheduling units are in each unit of

estimate (and work)

• Hours per day (how much work gets done each day)

The former affects the size of the task, the latter affects the duration. Both conversions were muddled up in _workHours() because we used to convert estimate to days and wrongly concluced we then needed to scale by hours per day to get work.

A failed case was an hour as a unit of estimate and a 6-hour work day (or a day when only 6 hours of work get done). With an estimate of 8, days per estimate of .125, and hours per day of 6, this gave:

hours = (8 * .125) * 6

Which converted the task for 8 hours to 6!

We first need to convert estimate to the unit of scheduling (hours) so days_per_estimate becomes hours_per_estimate. Computing work hours is then just (estimate * hours per estimate).

When scheduling, we divide work hours by hours per day to get days.

[Chris Nelson]

(In [10810]) Make hours per day a chart option. Refs #9042.

[Chris Nelson]

(In [10811]) Only convert the estimate from a string to a float once. Refs #9042.

[Chris Nelson]

(In [10812]) Fix up quotes (esp. triple quotes) in messages. Refs #9042.

[Chris Nelson]

(In [10816]) Correct percent complete calculation. Refs #9042.

[Chris Nelson]

(In [11069]) Handle implicit dates in parent tickets. Refs #9042, #9515.

Need to carry around an indication of whether the date is implicit or explicit.

[Chris Nelson]

(In [11072]) Refactor scheduling out of PM class. Refs #8982, #9042, #9515.

[Chris Nelson]

(In [11073]) Move Project Management stuff into its own module. Refs #8982, #9042, #9515.

[Chris Nelson]

(In [11074]) Make successor, predecessors consistent with parent, children. Refs #9042, #9515.

predecessors() and successors() returned lists of strings (e.g., ['123', '234']) but parent() returns an integer and children() returns a list of integers. Now all handle integers.

[Chris Nelson]

(In [11076]) Clean up start and finish handling. Refs #9042, #9515.

• Refactor start and finish parse routines to set time to midnight.

• Don't set time to midnight in values returned from parse routines.

• When defaulting to today, set time to midnight (including seconds, useconds)

[Chris Nelson]

(In [11077]) Rename percent() to percentComplete() for clarity. Refs #9042, #9515.

Some other refactoring of percent complete calculations.

[Chris Nelson]

(In [11078]) Use a function to create pseudo-tickets for milestones. Refs #9042.

[Chris Nelson]

(In [11079]) Cleaner date adjustment using calendarOffset. Refs #9533, #9300, #9042, #9515.

Scheduler used to assume work week. Now let calendarOffset() do that.

Also, it seems rounding errors would creep in and some datetimes would have non-zero microseconds. This tests for beginning and end of day with a little delta.

[Chris Nelson]

(In [11081]) Copy some dates before returning them. Refs #9042, #9515, #9533, #9300.

I'm not 100% sure why this is necessary but the wrong things seemed to get updated if I didn't do this and give demonstrably wrong results.

[Chris Nelson]

(In [11084]) Handle explicit finish with implicit start in ASAP schedule. Refs #9042, #9515.

And vice versa in ALAP.

Also removed unnecessary fixup of explicit start; parseStart() already zeros out those values.

[Chris Nelson]

Hows this working for you now?

[falkb]

Replying to ChrisNelson:

Hows this working for you now?

Today's SVN version:

situation: milestone date set and we have some unscheduled tickets

It looks good with ALAP:

• they always end at milestone date minus 1 day
• they are at the end of the chart list (and the milestone is the last one in the chart) <== BTW: Why is actually the word 'one' tagged?
• their start date is always end date minus planned hours

It looks almost good with ASAP:

• they always start today
• they are at the end of the chart list (and the milestone is the last one in the chart)
• remaining problem: tickets with many planned hours can end *after* the milestone date

[falkb]

Replying to falkb:

• remaining problem: tickets with many planned hours can end *after* the milestone date

Hmm... you may say: That's OK because the milestone is planned for a certain day, and such tickets we start today can have so many planned hours that it isn't possible to let it end before the milestone date.

But I suppose the ticket must start earlier than today in case we already have worked on it, which means the remaining hours are less than the planned hours. Then you must let it start on 'today minus already worked hours'. Here's illustrated what I mean:

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

Hows this working for you now?

Today's SVN version:

situation: milestone date set and we have some unscheduled tickets

It looks good with ALAP:

Great.

• they always end at milestone date minus 1 day
• they are at the end of the chart list (and the milestone is the last one in the chart) <== BTW: Why is actually the word 'one' tagged?

Apparently someone registered at T-H at user one and got a wiki page. Not sure if it was bogus playing or not.

• their start date is always end date minus planned hours

It looks almost good with ASAP:

• they always start today
• they are at the end of the chart list (and the milestone is the last one in the chart)
• remaining problem: tickets with many planned hours can end *after* the milestone date

I view a Gantt with dependencies that point leftward to be a red flag that I need to reschedule some stuff.

[Chris Nelson]

Replying to falkb:

Replying to falkb:

• remaining problem: tickets with many planned hours can end *after* the milestone date

Hmm... you may say: That's OK because the milestone is planned for a certain day, and such tickets we start today can have so many planned hours that it isn't possible to let it end before the milestone date.

But I suppose the ticket must start earlier than today in case we already have worked on it, which means the remaining hours are less than the planned hours. Then you must let it start on 'today minus already worked hours'. Here's illustrated what I mean:

I have had in the back of my mind for some time that an incomplete task should have its progress bar at today, not its start. I'm not sure how to do that, exactly. I think I need to break the task into two virtual tasks: one complete today and one starting today and schedule the first one back to its start and the second forward to its projected completion. But what if the first activity in the task was before of after the scheduled/projected start of completed work before today? Which start do I show?

It seems to me that the problem described in this ticket is addressed. Can you open a new one with a summary like, "Partially completed tasks should have unworked hours starting today" or something? Copying your figures from here would be awesome.

[falkb]

Replying to ChrisNelson:

But what if the first activity in the task was before of after the scheduled/projected start of completed work before today? Which start do I show?

That's exactly the problem I've addressed in #8786. Look at the attached image. I went to the future and made a screenshot how it'll be implemented...

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

But what if the first activity in the task was before of after the scheduled/projected start of completed work before today? Which start do I show?

That's exactly the problem I've addressed in #8786. Look at the attached image. I went to the future and made a screenshot how it'll be implemented...

Yeah, we may get there eventually. Now, if I only knew how soon in the future you took that screen shot, I'd know how soon I have to get working on this to finish on time. :-)

[anonymous]

Replying to ChrisNelson:

Replying to falkb:

Replying to ChrisNelson:

But what if the first activity in the task was before of after the scheduled/projected start of completed work before today? Which start do I show?

That's exactly the problem I've addressed in #8786. Look at the attached image. I went to the future and made a screenshot how it'll be implemented...

What I mean is that it's all much easier to handle if you separate done work from planned things. This implies work and plan become unchained from each other.

Yeah, we may get there eventually. Now, if I only knew how soon in the future you took that screen shot, I'd know how soon I have to get working on this to finish on time. :-)

You already know that knowing too much about the future changes the present and this can lead us on another time path which could be the failed one. ;)

[Chris Nelson]

(In [11419]) Add resource leveling to scheduler. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This is rather naive. It makes sure a resource isn't doing two things at once but doesn't yet handle priorities when conflicts occur.

[Chris Nelson]

(In [11422]) Add task sorter interface. Refs #9833, #9042, #9290, #9300, #9691, #9784.

[Chris Nelson]

(In [11423]) Add simple task sorter. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This sorts by Trac's built-in priority field (after converting the priority strings to integers).

[Chris Nelson]

(In [11424]) Implement prioritized scheduling. Refs #9833, #9042, #9290, #9300, #9691, #9784.

This is orthogonal to resource leveling. That is even if resource leveling is disabled, this schedules the tasks for a resource using the configured sorting rule.

[Chris Nelson]

(In [11426]) A tree-aware task sorter. Refs #9833, #9042, #9290, #9300, #9691, #9784.

A task's priority depends on its parent's priority.

Includes a base sorter class to hold common sorter methods.

SimpleSorter and ProjectSorter derive from the base class.

(Copy effective priority list, just in case.)

Also remove unneeded debugging output. Refs #9648.