johnblack
01-04-05, 10:19 PM
Hi all,
I'm posting this here, hoping the question will not overwhelm the core developers as I carefully tried to explore the way they're trying to cope with complex information flows and the preassure both comng from the community as well as that self-imposed.
The issue I've got is hopefully quite simle to explain, but still looks to me as a very useful feature.
Probably the best way is to give an example.
Let's say I assign 2 tasks to a person, and the 2 tasks partially overlap in terms of time period.
By default, it seems that dotProject simply fill the expected working hours per day by dividing the amount of hours allocated by the number of days available per task.
This can in some cases for instance bring about the situation where for some days we exceed 8h of work, while in the same time leave some other days "busy" less than 8h.
So, in the report, that to a project manager would appear as a conflict with that particular resource, even if with a simple "levelling" algorithm it would be possible to re-allocate the exceeding hours at those days that stay vacant or less busy, but still respecting the deadlines.
Such a levelling mechanism, that could be put an option when setting tasks, could potentially be highly useful to project managers having to manage larger groups of resources, but the problem appears evident already starting from groups exceeding 5-6 people.
Now, I personally am a programmer and maybe could try to work out a patch, as well as I (my company) would be willing to contribute to the dotProject marketplace if someone wishes to take on this.
Generally speaking, if this feature sounds of any use to someone, it is of course better to think how to embed it into the core project, rather than developing a plain patch. I've been following for some time the discussion in forums and over the mailing-list, and I believe this is also the orientation the core development team prefers most.
Clearly, I could prepare a more abstract and formal specification if this is of interest to someone.
Best regards.
I'm posting this here, hoping the question will not overwhelm the core developers as I carefully tried to explore the way they're trying to cope with complex information flows and the preassure both comng from the community as well as that self-imposed.
The issue I've got is hopefully quite simle to explain, but still looks to me as a very useful feature.
Probably the best way is to give an example.
Let's say I assign 2 tasks to a person, and the 2 tasks partially overlap in terms of time period.
By default, it seems that dotProject simply fill the expected working hours per day by dividing the amount of hours allocated by the number of days available per task.
This can in some cases for instance bring about the situation where for some days we exceed 8h of work, while in the same time leave some other days "busy" less than 8h.
So, in the report, that to a project manager would appear as a conflict with that particular resource, even if with a simple "levelling" algorithm it would be possible to re-allocate the exceeding hours at those days that stay vacant or less busy, but still respecting the deadlines.
Such a levelling mechanism, that could be put an option when setting tasks, could potentially be highly useful to project managers having to manage larger groups of resources, but the problem appears evident already starting from groups exceeding 5-6 people.
Now, I personally am a programmer and maybe could try to work out a patch, as well as I (my company) would be willing to contribute to the dotProject marketplace if someone wishes to take on this.
Generally speaking, if this feature sounds of any use to someone, it is of course better to think how to embed it into the core project, rather than developing a plain patch. I've been following for some time the discussion in forums and over the mailing-list, and I believe this is also the orientation the core development team prefers most.
Clearly, I could prepare a more abstract and formal specification if this is of interest to someone.
Best regards.