Better project management support

[anonymous]

Project Management Area

• Ability to input tasks and goals
• Ability to assign tasks to a login
• Ability to set estimate completion dates.
• Ability to define progress by hours or percent
• Ability to define subtasks
• Ability to view a overall gantt chart to view progress.

[jamesm@…]

Alot of the core functionality for this is already in place: * Tasks can be described as tickets * Tickets can be assigned to a user * Tickets can be assigned to a milestone

One approach on how to do this: * Subtasks could be tickets that have a parent ticket or a reference to other tickets (a workaround might be to include the parent ticket in the keywords?) * Progress by hours or percent is pretty much #364 * Gantt chart is related to #364, but the tasks/tickets would required two new fields: start date and estimated completion date. Without both dates you end of charting everything starting at either the same time or the ticket assignment date. Neither of those would be very useful as a Gantt chart.

Perhaps #364 should include an admin interface (and perhaps it already plans to have one) to facilitate this project management oriented approach.

[jamesm@…]

I messed up the Wiki formatting..... repeated properly

Alot of the core functionality for this is already in place:

• Tasks can be described as tickets
• Tickets can be assigned to a user
• Tickets can be assigned to a milestone

One approach on how to do this:

• Subtasks could be tickets that have a parent ticket or a reference to other tickets (a workaround might be to include the parent ticket in the keywords?)
• Progress by hours or percent is pretty much #364
• Gantt chart is related to #364, but the tasks/tickets would require two new fields: start date and estimated completion date. Without both dates you end charting starting at the ticket assignment date. That would not necessarily represent the actual development time for a ticket.

Perhaps #364 should include an admin interface (and perhaps it already plans to have one) to facilitate this project management oriented approach.

[anonymous]

I hate not being able to use my email address, Thats another feature trac needs.. A way to mask email address.

I think the problem with adding it directly into the ticket system, you risk making the ticket system to complicated for the average user. You would need to add at least 3 more fields to the tickets.

The type of project management we are talking about is for initial development and major releases. Projects that are done "developing" and just doing maintance work/fixing bugs no longer need the extra tools.

If its not "seperate" from current ticket system I see a few things needed

1. A on/off switch so its not there if not needed
2. A seperate page to manage/submit these "tickets" because a user should never be able to change this, and has no need to see the fields when filling out normal tickets.

[balk@…]

I'd rather we'd avoid the usual mistakes of trying to support gantt-charts instead of inserting the minimal amount of fields to support different kinds of followup.

1) To be able to follow up if it is realistic to keep a deadline, you only need the field "work_left (h)" added to the tickets.

2) To be able to follow up the amount of work done, perhaps in case you wan't to bill somebody for the work, you need to add "work_spent (h)" aswell. In combination with work_left you can also use this to calculate percentage of work done.

3) To be able to get early warnings of failed planning you need to add "work_budgeted (h)" aswell. Using this and work_spent you can calculate percentage of budgeted work spent, and more importatntly, in combination with work_left + work_spent you can in advance check if the current estimate of the work on a task is within budget. IE you can get early warning as soon as the estimate is done by the developer and you don't have to wait until the moment the budgeted hours is actually spent.

[barry.scott@…]

I agree with balk's comment. However * I plan in days not hours, this feaure would need to be flexible here * Turning work_left into elapse time needs to allow for scaling, which can take into account things like meetings, productivity, past track record (over/under estimates) etc.

[daniel]

Not really an actionable ticket. Move this discussion to the list and/or a wiki page, please.