After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132917 - Resource leveling
Resource leveling
Status: RESOLVED OBSOLETE
Product: planner
Classification: Other
Component: General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: planner-maint
planner-maint
: 129436 167521 318474 340340 393737 609998 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-29 21:53 UTC by jlquinn
Modified: 2021-06-09 20:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Planner file to explain planning method taking resources into account. (5.53 KB, application/x-planner)
2004-07-21 11:34 UTC, Xavier Ordoquy
Details
Illustration of mixed integer LP solution to scheduling with resource constraints (5.23 KB, text/plain)
2008-10-25 10:12 UTC, Jon Guiton
Details

Description jlquinn 2004-01-29 21:53:42 UTC
I have two tasks that have the same resource assigned to both tasks.  The
tasks remain parallel to each other, despite the resource conflict. 
Shouldn't one be forced beyond the other in time?
Comment 1 Xavier Ordoquy 2004-04-09 14:11:09 UTC
This has been discussed a lot on the mailing list and it ended up that there's
no reason we should prohibit such things.
Resource overload is possible and viewable in the resource usage view.
If you have an idea of how that should be handled, we would be pleased to hear
about.
Comment 2 jlquinn 2004-04-09 15:27:04 UTC
By default, I'd prefer to have someone who is assigned 100% to a task to force
the task not to overlap other tasks witht he same resource.  Otherwise, you
can't use the view to see the critical path.

Later, if you decide it's ok to either split time between multiple tasks, or
overcommit between tasks, then the system can work appropriately.

As is, the gantt chart makes it seem like a project would be finished way too
early since it effectively doesn't process the resource constraints.
Comment 3 Lincoln Phipps 2004-04-10 11:28:23 UTC
See also ,
http://bugzilla.gnome.org/show_bug.cgi?id=139443
as a thought on how we can handle contention for resources.
Comment 4 Jorge Godoy 2004-05-19 15:15:40 UTC
I would also like to see the possibility of having priorities to tasks
designated in such a way that the critical path was more visible *AND* dates are
more realistic.

By now, one have to add fake dependencies (FS/SF/etc.) between tasks to get then
ordered correctly.

The overlap of tasks also makes project time estimation less accurate, becaus
planner considers that both can be done in the same time, while we know that
physics prevents it (unfortunately ;-)).
Comment 5 Richard Hult 2004-06-18 23:12:37 UTC
*** Bug 129436 has been marked as a duplicate of this bug. ***
Comment 6 Xavier Ordoquy 2004-07-21 11:34:03 UTC
Created attachment 29735 [details]
Planner file to explain planning method taking resources into account.
Comment 7 Xavier Ordoquy 2004-07-21 11:34:33 UTC
Well, again, this has been discussed a lot on the mailing with example showing
that it's something very hard to do.
I'm joining a planner 0.12 file showing a very complex case to handle:
Task 2 is a very important task and should be handled ASAP and only one Resource
can handle it

Please note that the 3rd exemple is not correct on the resource usage view nor
on the work for task 1 (those are fake to get a correct render).
In that case, Resource 6 wouldn't have work on Task 1 on the 22 juily. Planner
doesn't handle the fact that some resources may not be working on a task during
some time which, imho, is a very hard thing to implement.
Comment 8 Lincoln Phipps 2004-07-25 07:47:55 UTC
For your example # 3,

Task split (with variable resource allocations) - The resource 6 allocation to
T1 could be stopped for the period that the T1 and T2 overlap. T2 could then be
worked on by R6 and then go back to T1. This does require us to implement task
splits with variable resource allocations. My current thoughts on task splits
was really saying that resources are allocated but not working (units = 0), so
why not also have attributes for the split that specifiy which resources are
still working or partly working ?. Going to be very hard to implement ;)

So......

Delay Task 2 - The T2 is just constrained to be ASAP after the Deliverable
milestone (which is constrained). Thus we could simply delay the start of T2 to
be after T1.

Delay Task 1 - If T1 was scheduled but had not actually started then its start
could be delayed to after T2. This does introduce some slack time.

Level Resource 6 Units - if the Resource 6 (which is in contention) is levelled
so that the total is 100% then this removes the contention. The trouble is that
there is no way of having a variable unit allocation for just the small period
of T1 that T2 is in progress. The effect is to increase the duration of both T1
and T2. This option only works if all resources are shared.

Which option to use ?. Without using a priority field there is no way of
determining which approach to take. This is why I'm lookng at priority as then
it becomes easier,

If T1 was higher than T2 then T2 would be delayed until T1 finished,
If T2 was higher than T1 then T1 could either be split (if T1 had already
started or if we had variable resources for splits) or T1 could be delayed to
start later than T2.

To do a task split with a variable resource allocation would be the ideal
approach but very hard to create.
Comment 9 Richard Hult 2005-10-13 19:39:16 UTC
*** Bug 318474 has been marked as a duplicate of this bug. ***
Comment 10 bill.haneman 2005-11-26 14:51:55 UTC
Guys, this is ridiculous.  One of the primary things planning software is
supposed to do is to assign resources/time.  Overloading a 'Work' resource
should be the exception, not the norm, i.e. the Gantt chart should not magically
allow a single resource to work at 100% effort on parallel tasks at the same time.

planner==useless until this is fixed.
Comment 11 Kurt Maute 2005-11-27 14:44:22 UTC
Bill, comments such as this add nothing to the discussion and get us no closer
to resolution.  If you'd like to inquire about the status of this change, the
planner mailing lists would be a better place to do it, and a bit more politely
I might add.

I'm adding you to the cc list on this request.
Comment 12 bill.haneman 2005-11-27 16:46:23 UTC
Kurt, the discussion on the mailing list seems to have had no effect.  Thanks
for adding me as a CC however.

I still think it's valid to note my point of view that this makes planner nearly
unusable for certain classes of application.  The bug is 18 months old, and
seems no closer to resolution after well over a year without any new comments. 
I expect you understand my frustration and surprise, and this my rudeness.

regards
Comment 13 gerd 2006-06-26 20:56:40 UTC
I'd like to have a resource leveling feature and still be able to sometime have a resource work overtime. The main reason for this is I sometimes confuse task dependecies that are required by the tasks and the ones I set to level resource usage. And not needing to set the latter would make planning require a lot less clicks.

Every resource should have a maximum utilization setting and every task a "allow working overtime" checkbox. If working overtime is permitted for a task the assigned resources can be utilized up to their max allowed utilization. If working overtime is not permitted, the resources are limited to 100%. This way you can limit working overtime to the precious tasks.

The question is when to schedule a task to work overtime if that is allowed for a task. I think it just makes sense for tasks that are on the critical path. 

Correct task priorization is important so I'd propose the following scheme:

1. critical path optimization to ensure that a task limiting the completion of the project is scheduled first
2. task priority setting
3. task order
Comment 14 Andrew Aksyonoff 2006-10-19 12:40:26 UTC
I found Planner when looking for free alternative to MS Project to create and manage projects of moderate size (~300-1000 tasks).

Everything else looks great, but having to insert fake dependencies is a showstopper.

The whole point with PM software for us is that we do NOT want to manually schedule 1000 tasks assigned to 30 people and/or update a gazillion links scattered across the schedule every time we need to update the project.

So Planner is useless for us until this is fixed as well - and it's a pity because everything else is in place and looks very good, simple and concise.

Seems that with a 2.5 year history the bug is not going to be solved any time soon, so we'll probably have to buy MS Project :(
Comment 15 Kurt Maute 2007-01-07 14:23:27 UTC
*** Bug 393737 has been marked as a duplicate of this bug. ***
Comment 16 Gábor Borgulya 2007-01-07 16:24:44 UTC
This bug is crucial for me to be able to use Planner. I even consider to code it myself, although I have only moderate experience in programming in C and the source of Planner looks huge and complicated to me at the first sight. I am astonished that this bug could get 3 years old.

Would it help other developers to solve the bug if I wrote a draft of a task scheduling algorithm?
Comment 17 Kurt Maute 2007-01-07 17:08:34 UTC
I'm actually working on this now.

There are actually some feature requests that are older than this one, and its not all that easy to implement...but this is by far the most frequently requested feature, so its top of my list.  Hopefully I'll have something for folks to test in a few weeks.
Comment 18 André Caldas 2007-05-07 19:13:35 UTC
(In reply to comment #17)
> I'm actually working on this now.
[...]
> Hopefully I'll have something for
> folks to test in a few weeks.

Why don't you share your thoughts? What was your conclusion on how scheduling should work?

Has anyone sketched it anywhere?
Comment 19 Gábor Borgulya 2007-05-07 20:46:27 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > I'm actually working on this now.
> [...]
> > Hopefully I'll have something for
> > folks to test in a few weeks.
> 
> Why don't you share your thoughts? What was your conclusion on how scheduling
> should work?
> 
> Has anyone sketched it anywhere?
> 

Me too, I would be glad to read a draft. Or even to contribute a draft. -- Gábor
Comment 20 Gary Bickford 2007-08-04 14:55:01 UTC
One can always construct situations that are too complex or pathological for any scheduling algorithm to accommodate, but the important thing is to provide something that is sufficient for, say, 80% or 90% of users.

I think the following would handle the most common situations, though I haven't delved into the code at all.  If a resource is assigned 100% to multiple parallel tasks with the same priority, AND that is the only resource assigned to the resources, then that resource's time would be split evenly among them.

More complex situations can be handled by proportioning the resource and task distribution according to assignment.  If I understand correctly, total per-task work hours must by definition be the sum of the adjusted resource allocations (e.g. 50% of A plus 40% of B, ... = N work hours) of all resources assigned to it.  If I am assigned 50% to a task, and you are assigned 30% to a task, then the working hours for the task will accrue at 80% of the full rate.

Add a new panel to the resource editing frame, which allows the user to adjust each resource's per-task allocation.

This approach still doesn't handle things like vacation and travel schedules, but it would solve the majority of allocation issues and would make Planner adequate for most of the posters to this thread.

In principle, the default for resource allocation _must_ be a maximum of 100%.  Adding support for overtime is a secondary priority.  The present default to allow maxima in excess is inappropriate; however it is reasonable to provide an option to allow maxima.

I would probably add one more factor - if a resource has been specifically allocated at, say, 30% to a task, then dynamic adjustment of resource allocation across tasks must respect and not change it (perhaps this is a preference option).

In the real world, engineering schedulers generally only allocate about 5 working hours per 8-hour day to projects - this is based on empirical evidence over many years.  Meetings, walking about, chatting, reading tech literature and other non-development activities take a surprising amount of time for most workers.  In my case, I work at home and can only bill for time actually spent doing development.  It is quite difficult to bill a full 8 hours without being 'in the saddle' for 10 or more.  
Comment 21 milli 2007-11-19 22:42:44 UTC
Any progress to report on this feature request?  Alpha code to test and/or contribute to?
Comment 22 sam 2008-02-27 15:27:02 UTC
Comment 20 has my vote.

And let the thickness of the gantt bar indicate the percentage load during a period.
Comment 23 Philip Frampton 2008-07-28 09:39:03 UTC
I've got a few suggestions for handling resource levelling:

1. Firstly, I agree with some of the above posters, without resource levelling Planner has limited use.

2. I think by default resource overloading (>100%) should simply be indicated on the Gantt chart perhaps by Red. You could also implement some kind of status bar feature to highlight that there are overloaded resources. The reason for this is that the Project Manager should be the 1st person to deal with resource loading (not the program itself).

3. Add a Resource Level option, which combined with priority, can schedule the work to complete in the shortest time without >100% resource use. This should probably have an override option to ignore individual priorities and minimize critical path. You need this because sometimes individual sections of a project are a priority and sometimes completion is the priority.

If you follow this method, you have the option of producing an overloaded work diagram, you have a tool to help the manager find clashes, and as a last result and automated process to level the resources.

Philip
Comment 24 Mat Nieuwenhoven 2008-09-25 04:20:34 UTC
I'm not sure if this is meant with 'task split', but I think a task should (by default) be seen as interruptable . For resource leveling, tasks are sorted by priority, then from the highest down resources are allocated. Anytime all needed resources are still available for a non-completed task it is scheduled. This will allow one to see what happens if a resource (say a person) is assigned to a higher level task for e.g. a week. Vacations, sickness etc. could be handled as highest-priority, non-interruptable tasks.
Like has be suggested before, if a resource is needed for two equal-priority tasks, the resource is split evenly between the tasks; but you might have to define a resource type that cannot be split, or better, define the time needed for a resource to switch tasks. E.g. a large crane could take a week to dismantle at one site, move it, and build it up again. Likewise, a developer might  take days to set up the test environment for a task, so switching between tasks 3 times a day wouldn't be a good idea...
Active tasks which are on hold for lack of resources could be indicated by a thin line on the Gannt chart.

Mat Nieuwenhoven
Comment 25 Philip Frampton 2008-09-25 06:30:01 UTC
Any resource that can be scaled from 0-100% has to be assumed to be splitable. Therefore you should and an option to "lock" a resource to 100%. A good example is the a crane on a large site. If it is needed in Position 1 for a week and then position 2 for a week you cannot schedule it 50% on two simultaneous tasks as it cannot be easily moved back and forth. I don't know what to call the option but some kind of tick box that greys-out the resource percentage at 100% and has a tool-tip that says something like "Select to prevent resource being shared by more than one task".

Also, further to my earlier post, I think any automatic resource levelling should use "earliest  completion of whole project" as the variable to minimise, and use priorities only when they don't affect that. The reason is, if the gantt chart hs been correctly created (with dependencies), then I can't think of a good example where the best resource levelling would not give the shortest project.

Well, in fact I came up with one example - and it's only when the project is an agglomeration of sub projects and getting individual parts completed allows for some advantage - eg building a new factory - the quicker you can get part of it finished the sooner you can start manufacturing - better to have half of it working in 2 weeks and the other half 3 weeks later than to have the whole thing done in 4 weeks.

So perhaps auto level should have to options "Optimise by Project Length" "Optimise by Priorities".

Philip
Comment 26 Mat Nieuwenhoven 2008-09-25 07:52:04 UTC
Looking at the XML file, I see that a task has a 'start' and 'end' . If we see this as the current computed start and end, then one could add 'suspend'/'resume' pairs for each time a task is interrupted for some reason, like a necessary resource not available. These pairs could be implemented as a linked list on a task, there could be hundreds. This would make it easy to play 'what if' games like "if a person works normally on a year-long task, but has to spend 3 hours a week on another, what would be the result if it was changed to 3 hours every two weeks?".

I'm sorry to disagree with Philip Frampton's suggestion to use priorities 'only when they don't effect..'. This is the whole crux of the problem. Priorities are set for a reason. If someone _has_ to spend time on an urgent problem, you want to know what knock-on effects this has. I don't want the planner to shift the highest priority task around. Priorities should be dealt with first, within equal priority task the planner can play around.

Mat Nieuwenhoven
Comment 27 Jon Guiton 2008-10-25 10:03:44 UTC
This is SUCH an important issue for the whole of the Gnome platform. Presently I do not have much time to help on this but I hope the following notes will be useful to the developers :

Some observations :

0. A `resource levelled' plan is a different version of the original.
 
1. Resource levelling should not be automatic. It is quite usual and useful to develop project plans without resources being initially levelled.

2. There are many possible algorithms for levelling resources - rescheduling approaches offer one possibility but in some cases increasing the resource works too (e.g. hire a second crane for a week).

3. Resources may be continuous or integer.

4. Although this is an NP complete problem it can be often be solved using a mixed integer linear programming approach that is highly efficient.

5. Some approaches to project planning use resource buffers whilst other approaches use mean time to completion. The appropriate levelling algorithm will depend on the characteristics of the project management approach.
 
Some consequences :

0. It should be possible to maintain different versions of a project with control over which is the present `live' version. In this way different versions can be compared and update emails will only be sent as a new version becomes the live version. This is good because project members do not get inundated with email traffic just because the project manager is trying out a new configuration.

1. Resource levelling should be an *action* that the project manager can apply to a project WHICH IS NOT LIVE. This way the results of levelling can be checked before project members are notified of changes (and then changes back etc.). It should be possible to easily compare different versions of the same project.

2. The resource levelling algorithm should be a plug-in and multiple algorithms should be supported. Then, the project manager can choose the most appropriate strategy e.g. if the mixed integer algorithm hasn't completed after 3 hours s/he might want to quickly find a solution based on the LP relaxation. Or, s/he might want an algorithm that can create new resources or some slippage may be allowed. These cases may be best handled by different algorithms. Also, the appropriate algorithms may depend on the approach taken to project planning.

A possible development path :

1. Support for project versions.

2. An ability to get a report that compares project versions.

3. An API for resource levelling algorithms and a plug-in architecture. 

4. Ship a mixed integer LP solver with planner for use by solvers. 

5. Possibly a characterisation of planning philosphy e.g. PERT or buffer based.

6. Plug in modules for a variety of approaches to resource levelling.

Sorry about the long post but this is SO important for Gnome - if it worked (i.e. if we had levelling) the planner would be a killer app for the uptake of Gnome in corporate environments because unlike M$ it is truly integrated into the desktop architecture. PS I'll attach an LP formulation that might help - no 
guarantee this works or anything - just illustrates the approach.

JonG
Comment 28 Jon Guiton 2008-10-25 10:12:12 UTC
Created attachment 121335 [details]
Illustration of mixed integer LP solution to scheduling with resource constraints

I'm not sure this works - but I believe the basic structure is ok and it illustrates an approach. In fact we would want to use the API of the solver so a MIPS formulation might be more useful see http://www.gnu.org/software/glpk/ for details of one solver.
Comment 29 Massimo Franco 2008-10-27 13:23:37 UTC
I agree Jon,

One thing that could be possible through the versionning is the difference between the theoretical planning and the live one. So you can see where things has gone wrong.

Max
Comment 30 Robert Krawitz 2008-11-21 19:27:18 UTC
Rather than getting too clever with optimization (at least at first),
how about something like this (in pseudo-code):

foreach t (all_tasks) {
  d = t.start_date
  while (d < t.start_date + t.duration) {
    if (resource.loading[d] > resource.max_loading[d]) {
      t.start_date = d + 1
    }
    d++
  }
  for (d = t.start_date; d < t.start_date + t.duration; d++) {
    resource.loading[d]++
  }
}

This obviously doesn't handle partial assignment (someone's assigned
to a project 50%), but that shouldn't be a big deal to handle.  It
also has the property that the schedule will change depending upon the
order in which tasks are listed, and it doesn't account for
interruptions (split tasks), and it doesn't handle priorities (which
could possibly be handled by sorting the tasks other than top to
bottom), but those are optimizations that could be handled later.

Something like this would at least get us resource leveling, which
really is critical for use in e. g. planning software development.
Comment 31 Jon Guiton 2009-04-16 21:45:50 UTC
Robert,

Thanks for the feedback and code snippet. You seem to be suggesting that there is a simpler approach that we could take to resolve this bug.

I'm not sure I go with that. Resource levelling is an optimisation problem so not going with that just isn't clever enough - wouldn't we just end up re-inventing linear optimisation?  Also your code doesn't work - it is not enough to just delay the start of the activity. Your attempt is valiant but this is not an easy problem to resolve. Also, as you say your solution doesn't handle many issues - *optimisations* that can be handled later - but why? The simple solution is to use the known method for solving them all at once.

Why not just use the existing solution - a mixed integer linear program. This will perform well and there are many highly developed GPL libraries that do this.

The issue is *integration* of a solution with the rest of the application in a manner that doesn't break it. Remember that as things stand, delaying the start of an activity by a day might generate a torrent of email notifications to project members. 

Finally, as you say - resource levelling *is* critical for this component - it is an embarrassment to open source software that our integrated planner doesn;t plan (IMHO) and a great shame because the rest of the application rocks. My fear is that a quick fix will create more problems than it solves and will never provide a complete solution without re-inventing mix integer programming which is probably a bigger job than developing Gnome. No, I say go with a properly engineered solution that fixes the problem once and for all time and which provides users with a state of the art desktop.

Let us try to build a consensus around this as a solution to resource levelling and then get it implemented in time for Gnome 3.0.

Jon 
Comment 32 Deven T. Corzine 2009-04-17 19:19:29 UTC
Jon,

You say there's known solutions to this problem an "many highly developed GPL libraries that do this."  Can you elaborate?  What libraries and algorithms are out there?  What's the quality of those libraries?  Integrating a known solution to a known problem should be much easier for someone to do than designing and implementing a new algorithm to solve the problem.

Also, looking over the history of this bug, a number of people seem to view this as a showstopper bug.  There was one offer made for a bounty for this:

http://mail.gnome.org/archives/planner-dev-list/2008-June/msg00000.html

I don't know if that offer still stands, since it was from last year, but it sounds like quite a lot of money is being spent on Microsoft Project by people who would rather use this software, but for this bug.  Perhaps it would help if people in a position to save a lot of money on licenses could pool that money together for a bounty -- the larger the bounty, the more incentive there is for someone to jump in and fix the bug, especially if there's a known solution that can be integrated to solve the problem.

Deven
Comment 33 Jon Guiton 2009-04-17 23:30:39 UTC
Devon,

Thanks for the interest. Let me elaborate on the known solution to this 
problem :

Resource levelling is one aspect of the more general project scheduling problem. This general scheduling problem has been widely studied by Operations Researchers since the 1950s and modern project management techniques were developed based on this research effort. The problem is that whilst Planner is a good tool for capturing project related information (activities, resources etc) and for displaying them it doesn't actually perform any scheduling related computation - as you say, a show stopper.  

General scheduling can be modelled as a mixed integer (linear) programming problem. Such a model consist of an objective function to be minimised (for scheduling this is the project duration) and sets of constraints on the possible solutions. Some of these constraints model the structure of the project network whilst others enforce the rules that no resource should be used at more than 100% capacity. Other constraints can be included. See attached document http://bugzilla.gnome.org/attachment.cgi?id=121335 for an (crude) example of such a model using the Gnu MathProg modelling language that ships with the GLPK solver.

Such a problem can be solved by a linear optimiser using a variety of methods including dual simplex or branch and bound approached. See 
http://www.gnu.org/software/glpk/ for a package that can solve this - probably this is one of the best solvers in the world, is mature and is entirely free. GLPK has been used to design spacecraft! There are also other open source solvers, see http://cran.r-project.org/web/views/Optimization.html for a decent list of packages used in science, engineering, Government and industry.

This problem falls into a class of problems which whilst theoretically NP complete (require exponential time) can nevertheless be solved for large problem sizes in reasonable time using this approach. In general a project with thousands of activities and thousands of resource constraints could be solved in a reasonable time (minutes) using a decent solver, whilst smaller problems might take only milliseconds. This might not be true of a 'homebrewed' approach which could run into serious time complexity issues.

In the attached example the project is modelled in MathProg. For Planner this would not be the case. Activity and resource constraints would be modelled as matrices (arrays) and the solver could be called directly using these parameters (however, GLPK now includes a special module for solving problems on graphs and networks so that might be even easier). The output is a revised project schedule with resources levelled that also satisfies any other constraints. Thus, solving the big problem turns out to be quite easy except that as I explain in my previous post
http://bugzilla.gnome.org/show_bug.cgi?id=132917#c27 there are some issues with integration. However, in that post I propose an outline methodology for resolving these integration issues.

A clever solution would iterate finding an optimal network in order to solve the quadratic optimisation problem (QP) of also minimising cost.  There are many other possibilities which is why I suggest some degree of plugin architecture/modularity here. The project manager may need/want to be able to specify additional constraints or choose from a variety of optimisation strategies. Such a solver would frankly be a world beater.

In order to use this approach some choice of solver would need to be made and this would have to be shipped with Gnome. This is a *brilliant opportunity* to
equip Gnome with a decent optimiser in time for Gnome 3.0. Many problems in Gnome from complex window placement/interpolation/packing problems could also make use of this. Lots of linux applications from gcc to metacity need to solve similar mixed integer programs. If Gnome 3.0 is to offer some new stuff for developers including an optimiser would be an excellent choice.

(Sorry if this is now a bit of a rant but ...)
I said in my previous post that it was an embarrassment to the open source community that our planner doesn't plan. It is also (IMHO) an embarrassment that this 'bug' has been outstanding for over five years and that it continues to be listed with priority and severity *normal*. This should be listed as being a VERY SERIOUS problem which is a CRITICAL priority since libplanner is actually entirely broken because of it. Giving the 'bug' an appropriate status might actually do more to get this solved than a big bounty and I strongly believe that if as developers we all fully appreciated the potential of integrating optimisation solutions into our libraries it would be. LETS GET IT FIXED BEFORE GNOME 3.0. 

To make a start here we immediately need VERSIONING of projects in Planner, if this was implemented (others can do a better job than I can) I would be happy to play a part in integrating the solver if need be (and I have time in the summer) - although I can't do anything until then. Nevertheless, if there is activity here I'm happy to share what I know about optimising networks and I will keep tracking this.

Jon
 
Comment 34 Alexandre Franke 2009-05-21 23:50:09 UTC
*** Bug 340340 has been marked as a duplicate of this bug. ***
Comment 35 Alexandre Franke 2009-05-21 23:50:32 UTC
*** Bug 167521 has been marked as a duplicate of this bug. ***
Comment 36 Christian Obkircher 2009-07-16 22:07:45 UTC
Generally, I think that project monitoring is too complicated in planner. You CAN see that a resource is overloaded, but only when you go to the resource usage section and scroll through the whole project.
I agree that resource leveling is an action that should not be live. In MS project you need to initiate this manually, too. *BUT* I think there should be a general alert function that warns you when there are conflicts like resource overload or a potential delay.
Maybe there could be an icon in the (now empty) status bar or something like the pop-up notification in Firefox.

Also, planner lacks of a project update feature. What if a task, or even the whole project is paused for some time? (Illness, weather conditions, legal issues... you know what I mean)

Task progress is entered in percent. This might be correct when progress can be measured in an absolute way, like how complete a wall or how long a tunnel is. But in software projects you might notice that a task is more complex than you thought, so you add more work to it. But doubling the work doubles the progress too, since it's percentual. You have to recalculate the progress for yourself. It would be better if you could specify progress in absolute numbers, and the percentage would be calculated automatically.

I would like to help with this, but I'm a bit lost in the source code. Is there a general documentation about code organization and data structure? I never contributed to an open source project before, I just don't know where to start.

Christian
Comment 37 Christian Obkircher 2009-07-17 17:44:01 UTC
Does anybody know TaskJuggler? Take a look at http://taskjuggler.org/
It has everything we need: resource leveling, different scenarios, flexible working hours and vacation handling, project tracking and status recording... It's a command line tool with a KDE-GUI on top. Project data is entered in an embedded text editor (alternatively, any text editor can be used), which is very powerful but not very comfortable.
I did not try it out so far, but the feature-list looks very promising.

It's futile to waste resources on already solved problems. So, why invent the wheel again? This is where the power of open source software lies!

I think there are 3 possibilities:

* transform Planner to be another, more comfortable GUI for taskjuggler
* use just some libraries of it (I don't know if this is possible, I didn't take a look on the code so far)
* just copy the relevant snippets of code (a not-so-good solution IMHO)

What do you think about it?
Comment 38 Paul Clark 2009-11-27 13:19:52 UTC
If I can just add my two-penn-'orth to this...  I've just started using Planner for a medium-sized software project and found it very useful - so thanks!  But as as others have said, not having any way of automatically scheduling to avoid resource overcommitments makes it rather more manual than one would like.

But note I didn't say "resource levelling".  I remember using this in MS Project many years ago and unless you set up endless constraints beforehand you could wave goodbye to any sanity trying to unpick what it did.  In particular, you could end up with programmers switching tasks every day - not productive.

Plus, since this has been open for so long I'm guessing the developers think it's all a bit too much to tackle, so here's a suggestion of something simple and doable rather than Correct and Complete.

To my mind, all I want is a simple way to create chains (staircases) of tasks which can't realistically happen at the same time because they share the same resource, but don't necessarily have real interdependencies - for example, multiple peer-level modules.  To do this, you currently have to add fake dependencies, but they look the same as real ones.

So as a really basic fix, could there be a way to mark a dependency as a manual resource allocation fix, rather than a real one, and have it displayed differently on the Gantt (maybe red dots)?  Then at least one could manage the resources by juggling these without having to think about whether they are real or not.

The next level up would be to have a very simplistic menu option to try to fix overallocation by creating these fake dependencies (first deleting all the old ones) - something like this:

1) Have a "maximum allocation" field for each resource, defaulted to 100%.

2) In task number order, if the normal earliest start time (based on constraints/dependencies, but without the fake ones) would cause a resource to go above the maximum allocation, create a fake dependency on the last previous task that uses that resource.

I think this would create my "staircase" patterns, which is quite a step up from doing it manually;  it's also predictable, and reflects the fact that in my plans, at least, tasks are numbered roughly in execution order.  To reorder two tasks, you just move one up the list, and rerun the "fix" tool (or maybe it could run automatically, as an option?)

Maybe to limit any damage, you could run this at a particular summary-task level, and have it apply only to sub-tasks (recursively)?

And yes, it doesn't do anything fancy like splitting tasks - that's a good thing, as far as I'm concerned!  I already break things down into work units that represent a quantum of concentration for a programmer - max 5 days each item.  I don't want them split any more than this, otherwise everyone starts thrashing.  If I had to split one to allow some critical task to get done in the middle, that's up to me to create "Wombat (A)" and "Wombat (B)" subtasks and (in my simple idea above), re-order the tasks "Wombat (A)", "Critical", "Wombat (B)" and re-run "fix".  In my mind, that's better than the current situation of having to do the split and put dependencies in manually.

So KISS, but soon, please!

Many thanks

Paul
Comment 39 Alexandre Franke 2010-02-15 15:35:43 UTC
*** Bug 609998 has been marked as a duplicate of this bug. ***
Comment 40 paul.bussmann 2010-04-11 13:42:21 UTC
I took a look at TaskJuggler as Christian mentioned above and it seems to do the job: schedule the tasks according to rules including "Automatic resource leveling and tasks conflict resolution".

May be it's a good idea to write a converter from planner-files to TaskJuggler-files. Then run TaskJuggler with the transformed planner-file and check if the resulting calendars do have correctly resolved the conflics. If this works well it would be a good idea to have the results of TaskJuggler transformed back to planner-files afterwards. When re-transformation exposes no problems this procedure could be included into planner.
Please let me know if it is reasonable to do so, who would be interested in this setup and who may even help doing so.

Paul
Comment 41 Alexandre Franke 2010-04-11 14:58:56 UTC
I don't think the Planner->TaskJuggler->Planner format conversion is a good idea. We should rather get their logic implemented in Planner. We can't really borrow their code since it seems to be ruby, but we could definitely ask them for help.
Comment 42 paul.bussmann 2010-04-11 19:25:03 UTC
I guess it is a non trivial task to re-implement the ruby-wheel even with the help of the TaskJuggler's guys. It may easily take months of coding, look how long this issue is still unresolved! Converting from one program's format to the other is something really interesting anyway concerning interopability between GNOME and KDE tools. Additionally to the fact that the programs would get compatible to each other, planner would get a step closer to its resource leveling feature that actually keeps planner in my eyes as something "not ready to use".

Paul
Comment 43 Alex 2012-12-10 11:36:24 UTC
Has there been any progress on this bug? I'm also trying to use planner and this makes its use very limited. I think Jon G.'s proposal above looks very reasonable. It's really a shame that this feature isn't supported -- planner is one of the few open source project management tools that is not hopelessly buggy.
Comment 44 Alexandre Franke 2012-12-10 14:18:36 UTC
Nothing new on that topic (or obviously it would be on this page).
Comment 45 Alex 2012-12-10 15:02:15 UTC
Is there a particular hold up? I'm trying to see if I could help, but not sure where to start. Is it possible to use GLPK as a dependency as was suggested by Jon Guiton above?
Comment 46 fr33domlover 2013-06-12 08:09:08 UTC
Nothing yet?

I'm writing a set of general purpose CPM/PERT/WBS algorithms including the ones all project management programs use, and that includes Planner. Maybe you could use my code when it ready... just like I look at planner code and learn from it :)

(I'd like to help Planner directly, but personally I hardly find my way through the code. Is there a document explaning the algorithms used by Planner? Comments in the code explain some of them, but mostly it's quite difficult to navigate there unfortunately.)

As to GLPK, using a solver is a great way to reduce the problems to LP and just let LP do the math. It's much faster to write than manual algorithms, and since Planner is developed slowly (I guess it's because devs are busy), LP is a fast solution which brings immediate results.

Planner has great potential, I'd like to see it used in more projects.
Comment 47 Luc Pi 2013-06-13 09:24:59 UTC
Another method to order tasks, is to order them randomly. This is a super simple algorithm and it is super fast to run - unbeatable.

Now to get a good ordering of your tasks, you run this random algorithm multiple times. Lets say 10.000 times. And you take the best solution among all.

This solution has great chance to be "a good one".

While it is not deterministic, it beats many ordering algorithm and strategies.
Comment 48 fr33domlover 2013-06-13 12:31:17 UTC
But what happens when you need to consider real world data after the project starts, like tasks finishing before or after the expected time? If you make a new random arrangement, you may get something very different from the original plan.

Won't you have to use a deterministic algorithm? (so that you get the a result to what's been planned, and adapting to the real-time changes will require minimal changes/damage)
Comment 49 Luc Pi 2013-06-13 12:44:36 UTC
(In reply to comment #48)
> But what happens when you need to consider real world data after the project
> starts, like tasks finishing before or after the expected time? If you make a
> new random arrangement, you may get something very different from the original
> plan.

Same thing with a deterministic algorithm, the new arrangement can be very different, unless you have a specific algorithm that minimizes change.


> Won't you have to use a deterministic algorithm? (so that you get the a result
> to what's been planned, and adapting to the real-time changes will require
> minimal changes/damage)

Do you mean that you have independent components in your problem? Then it is fair to re-arrange only the independent component that changed.
Comment 50 fr33domlover 2013-06-13 13:07:05 UTC
I mean a deterministic algorithm can minimize change. Anyway, I guess a random algorith is worth trying. For large projects it may be much fastet.
Comment 51 GNOME Infrastructure Team 2021-06-09 20:28:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/World/planner/-/issues/35.