On Thu, Dec 04, 2008 at 04:34:25PM +0000, Lee Baylis wrote: >> The % should be clarified as bug #387985 suggests. > I'll fix this and send with my forthcoming patches for 'no overallocation > permitted'. >>> The idea, as far as I can tell from reading discussions in bugzilla, is >>> that people should be able to choose whether or not they actually want >>> 100(%) to be hard-coded as a maximum. >> >> Could you give some links or bug numbers? >> > The main place I saw reference to this was Lincoln Phipps' document > attached to bug #139443 - in the resource default usage section he makes > reference to a quantity 'MaxUnits', and in the appendix he sets out what is > intended by this quantity. He gives an additional use case where resources > are not individuals but rather teams, and different teams might have > different sizes and therefore need different maximums. >>> However, it is also usable to represent other circumstances - if you know >>> one resource is more efficient than another, for example. Then resource >>> 1, an experienced worker, could have a maximum of 100, and resource 2, an >>> apprentice, could have a maximum of maybe 65. >> >> The effort estimate (work) that was entered for the task must already >> have been made with some efficiency in mind. Why use another level of >> efficiencies in the scheduling stage? >> > I think your above statement assumes that the project manager already knows > which resources will be assigned to the task at the time of entering the > task into the project. > Whilst this may often be the case, surely enforcing it as an assumption > impacts upon the flexibility of planner as a tool which can assign > resources to tasks at any time, unless you are suggesting that a task's > work should be manually re-edited every time a user assigns an additional > resource to a task? >> Also setting a fixed efficiency ratio between people will not fit in all >> situations, because one person could be more efficient at one thing >> while the other is more efficient at another. >> > Here, I think, it would be left open to the user as to what they use the > field for. If the user is comfortable with making efficiency estimates, the > field could be used as an efficiency. If the user was using teams, as > Lincoln suggested, then it could be used for that instead. The main thing > would be that we had introduced some way for people to try and get around > whichever problem they were having whereby all resources having a maximum > of 100% wasn't flexible enough. Ok, I am now convinced that the feature can be useful and that it does not need to be 'yet another vague tunable value' in the UI. What we should do to round this off is: - clearly show in the UI that it's a percentage (as you said you would do) - in the description in the manual add a few simple use cases (teams, rookie vs pro). - choose a sensible default when allocating resources to a task I think the last one should be max units by default, what do you think? > A further use case might be if a project manager was managing several > projects which had a resource in common - for example: > > Resource #1 is working full time on project #1 > Resource #2 is working 50% on project #1 and 50% on project #2 > Resource #3 is working full time on project #2 > > The project manager has two planner files detailing the different projects, > but wants to make sure time allocations for resource 2 are respected across > both. Using a 50% maximum for resource 2 in each project would achieve > this. I'd prefer to use the calendar for this, but there's nothing stopping someone from using the max units for this purpose. I would not mention this as a use case in the manual though. >> For me a good feature: >> - is useful for a large enough number of people >> - provides functionality that is not yet provided in different but just >> as fitting ways by existing features >> - provides more or less complete functionality for that feature >> > The third point is difficult to satisfy when we start talking about > efficiencies, as there are many complicated ways to approximate the problem > which a simple field cannot solve. However, I think Lincoln's example and > the multiple project use case cover all three, and if implementing this > feature to solve those problems additionally offers a starting point for > users who want to try and solve efficiency problems, I would say so much > the better. Ok. >> I agree that keeping a global list of edges is not the way to go. And my >> comment was merely about units_in_use. I can live with people having to >> throw away the edges list, but I'd like some assertions that trigger in >> the >> following situation: >> >> mrp_assignment_edges_insert_sorted_from_assignment() >> mrp_assignment_edges_plot_units_in_use() >> mrp_assignment_edges_insert_sorted_from_assignment() >> mrp_assignment_edges_calculate_max_units_in_use() >> >> How about just setting units_in_use to -1 upon creation of the edges and >> then asserting in mrp_assignment_edges_calculate_max_units_in_use and >> whereever else units_in_use is accessed. >> > OK - I have amended the files and think this is covered in the attached > patches. I'll look at them when I have some time. Hopefully during the Christmas holidays. >>>>> mrp-assignment: >>>>> >>>> mrp_assignment_edges_remove_to_last_before and >>>> mrp_assignment_edges_remove_from_first_after. Now that they are two >>>> separate functions, I have ditched the two g_list_reverses, and used >>>> g_list_last instead. >>>> >> >> Ah, I see. About that, g_list_last needs to traverse the list and I >> think you can use last = last->prev just before g_list_delete_link, >> right? >> >> I'm not trying to be a nitpick, but somehow I just can't let these cheap >> optimisations slip by ;-) >> > Not at all, you're quite right! I have corrected this as well in the > attached patches. It's quite ok to keep these things on-list. Best regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer griffon26 gentoo org http://www.gentoo.org Gnome Planner Developer griffon26 kfk4ever com http://live.gnome.org/Planner
Attachment:
pgptWIL9cvrOv.pgp
Description: PGP signature