Why 30? That is assuming that most people will assign about 3 people per task ... I though 100 made more sense

Nope. I had quite a discussion with Gregor and other people about this issue.

It's a major misunderstanding or maybe better 'disagreement', what the percentage is used for.

You assume, that the percentage indicates how one single task is divided between people, e.g. User A is doing 60% and user B does 40% of this task.

I see it different. The percentage is user specific and not task specific. If a user get's a 40% in a task, he works 40% of his time on this single task and 60% on other things. How a single task is divided between the people is up to them, they can divide the task in subtask with individual packages.

If I see a name and a percentage, I assume that this number is the total workload of a user.

Wendebaum, that's what I figured it was too.

Is it actually task-based?

Now that makes more sense :) Still, I'm not sure which way I would find it more useful. Perhaps this needs clarification so user knows what the percentage refers to.

Wendebaum's interpretation is the one I would make too I think - and more importantly my 'business' users would probably make the same. It makes it easier to see when a person is over-allocated at any one time.

There are a couple more problems if this is the accepted interpretation - how would a project supervisor know what percent of the time a user can work on a task, if the user works on multiple projects, managed by different supervisors?

At the moment, how is the allocation working? I.e., when the percentage goes back to 0% (or 100?%). Half of my users show at 100%, and the other half at 0% when the task doesn't have dates (I think when there are no dates, it searches for all dates, which is not correct behaviour I don't think).

In our business it is not allowed to have a task without a date. Such a task would never be worked on as there are other tasks which have deadlines and are to be worked on. Tasks without a deadline are to be put into the helpdesk module. This is the handling at least in our firm.

This does make sense ... but is not enforced by dotProject and there is no documentation for users to know to use it that way. Shouldn't it handle the more generic situations as well? I'm just trying to understand it better - not trying to create more work :)

You are right. Maybe a switch to allow overassignment would be helpful at first...

Perhaps it makes sense to allow overassignment for now, and have a report that shows who is overassigned, and by how much.

On the basis that a tool like dotproject isn't a replacement for process but should aid it, matters like that should be resolvable by the wetware element of the system ;-)

I agree with camden *as long as* the overassignment is noted clearly somewhere... requiring the task assigner to click on a "Yes, I know I'm overassigning this person" should always happen, but it should also be noted elsewhere...

*** Post created in another thread, repeated here. Sorry, I need to clarify this problem ASAP ***

There is one issue that I would like to understand:

Example:
- I have one task for today that I allocate 100%
-> It will take me all day
- I have one task for tomorrow, that will also take me all day (100%)

The current CVS version will not enable me to create the second task because I'm allready 100% allocated (0% free).

The issue here is that I might have a task that needs to be done within next year, and I will not be able to assign it to me (plan) because now (not next year) I'm overallocated.

How am I suppose to solve this problem?

That's infact a problem and bug that needs to be fixed...

I'll have chat with Gregor and see what the requirement really is, and then help him to resolve any issues with the implementation.

Hey all. Just curious if a decision has been made on this...

Yes, I'm also curious. thank you!

I've spoken to Gregor, and the proposal is to remove the task over allocation limit as it currently stands, and instead to create a report that properly handles the time factor. This is to allow people to use the product in the meantime, without losing too much functionality, while we reconsider the logic used for task over allocation. Once we have a solid method of determining time-based over allocation, it will be reintroduced.

Any comments/complaints/suggestions to me please.

I think it's a good idea. Perhaps not removing it completly, it can survive well if it allows the user to assign the task and showing within the status bar that the user is overallocated. While the issues are solved, this can exists.

Thank you for the reply!

yep some clarification would be great... at the moment this percentage has to be an arbitary number so I can include all the tasks that need to get done now and in the future...

also how do I get my percentage allocation back. It seems that even if I have completed a task the percentage allocation remains the same untill I go and reallocate it back, which doesn't make sense. If I've finished the task then I'm not going to spend anymore time on it, am I?