Modify

Opened 3 years ago

Last modified 3 years ago

#9042 assigned enhancement

Display unscheduled tasks at the end of the milestone

Reported by: rjollos Owned by: ChrisNelson
Priority: normal Component: TracJsGanttPlugin
Severity: normal Keywords:
Cc: bof Trac Release: 0.11

Description

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.

Attachments (2)

9042_asap_unsched_tick_NOK.jpg (4.2 KB) - added by falkb 3 years ago.
9042_asap_unsched_tick_OK.jpg (6.6 KB) - added by falkb 3 years ago.

Download all attachments as: .zip

Change History (48)

comment:1 Changed 3 years ago by rjollos

  • Summary changed from Move unscheduled tasks to end of milestone to Display unscheduled tasks at the end of the milestone

comment:2 follow-up: Changed 3 years ago by ChrisNelson

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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by 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?

comment:4 in reply to: ↑ 3 Changed 3 years ago by ChrisNelson

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.

comment:5 follow-up: Changed 3 years ago by ChrisNelson

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

comment:6 in reply to: ↑ 5 Changed 3 years ago by rjollos

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 ;)

comment:7 Changed 3 years ago by ChrisNelson

(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

comment:8 Changed 3 years ago by ChrisNelson

(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.

comment:9 Changed 3 years ago by ChrisNelson

(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.

comment:10 Changed 3 years ago by ChrisNelson

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

comment:11 Changed 3 years ago by ChrisNelson

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

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

comment:12 Changed 3 years ago by ChrisNelson

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

comment:13 Changed 3 years ago by ChrisNelson

(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.

comment:14 Changed 3 years ago by anonymous

  • Status changed from new to assigned

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.

comment:15 Changed 3 years ago by ChrisNelson

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

comment:16 Changed 3 years ago by ChrisNelson

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

comment:17 follow-up: Changed 3 years ago by rjollos

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

comment:18 in reply to: ↑ 17 Changed 3 years ago by rjollos

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.

comment:19 Changed 3 years ago by ChrisNelson

(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.

comment:20 Changed 3 years ago by ChrisNelson

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

comment:21 Changed 3 years ago by ChrisNelson

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

comment:22 Changed 3 years ago by ChrisNelson

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

comment:23 Changed 3 years ago by ChrisNelson

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

comment:24 Changed 3 years ago by ChrisNelson

(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.

comment:25 Changed 3 years ago by ChrisNelson

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

comment:26 Changed 3 years ago by ChrisNelson

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

comment:27 Changed 3 years ago by ChrisNelson

(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.

comment:28 Changed 3 years ago by ChrisNelson

(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)

comment:29 Changed 3 years ago by ChrisNelson

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

Some other refactoring of percent complete calculations.

comment:30 Changed 3 years ago by ChrisNelson

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

comment:31 Changed 3 years ago by ChrisNelson

(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.

comment:32 Changed 3 years ago by ChrisNelson

(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.

comment:33 Changed 3 years ago by ChrisNelson

(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.

comment:34 follow-up: Changed 3 years ago by ChrisNelson

Hows this working for you now?

comment:35 in reply to: ↑ 34 ; follow-ups: Changed 3 years ago by 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

comment:36 in reply to: ↑ 35 ; follow-up: Changed 3 years ago by 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:

Changed 3 years ago by falkb

Changed 3 years ago by falkb

comment:37 in reply to: ↑ 35 Changed 3 years ago by ChrisNelson

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.

comment:38 in reply to: ↑ 36 ; follow-up: Changed 3 years ago by ChrisNelson

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.

comment:39 in reply to: ↑ 38 ; follow-up: Changed 3 years ago by 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...

comment:40 in reply to: ↑ 39 ; follow-up: Changed 3 years ago by 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...

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. :-)

comment:41 in reply to: ↑ 40 Changed 3 years ago by 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. ;)

comment:42 Changed 3 years ago by ChrisNelson

(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.

comment:43 Changed 3 years ago by ChrisNelson

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

comment:44 Changed 3 years ago by ChrisNelson

(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).

comment:45 Changed 3 years ago by ChrisNelson

(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.

comment:46 Changed 3 years ago by ChrisNelson

(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.

Add Comment

Modify Ticket

Action
as assigned The owner will remain ChrisNelson.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.