if fields.start and fields.finish not set in trac.ini, use datetime of 'accepted' and 'closed'

[falkb]

This way, if we don't schedule tickets, we could use this Gantt chart as time survey over the done activities.

This is somehow related to #8786.

Addon: we also have the ticket state 'testing' before 'closed'. Would be cool if the Gantt chart bar changes the color after the state switch.

[Ryan J Ollos]

+1 for this general idea of using the accepted and closed times, in some form or another.

[falkb]

Is there an easy way how to find out the timestamp of when e.g. state 'accepted' has been entered?

[Ryan J Ollos]

Replying to falkb:

Is there an easy way how to find out the timestamp of when e.g. state 'accepted' has been entered?

Trac stores this information in the ticket_change table, ​t:TracDev/DatabaseSchema#DatabaseSchema. If you aren't familiar with SQLite, I'd suggest using the ​SQLite Manager for Firefox, which allows you to easily open, view and manipulate an SQLite database.

[falkb]

I just thought I could make a patch for this ticket. But first, I need to find out how to code the access of the timestamps of ticket state transitions. That's why I asked.

[Chris Nelson]

So, I'm looking into this and I'm unsure what "accepted" means. It seems to me that the only statuses you can be 100% sure exist are new and closed.

For my purposes, I say that a ticket is closed the last time it transitions from any status to closed (that is ticket_change contains (field="status", newvalue="closed",) regardless of the contents of oldvalue) then ticket_change.time is when the ticket was closed.

Similarly, work on the ticket begins on the first transition from new to any other status. No doubt accepted is one of those.

BTW, I imagine using this as the close (and start) time whether or not the start and finish fields are configured. Does that make sense to you?

[falkb]

Well, these are just my thoughts about the fact that it's not sufficient to simply use transitions to or from states 'new' and 'closed':

Replying to ChrisNelson:

Similarly, work on the ticket begins on the first transition from new to any other status.

No, not 'new' to any other.

There are several workflows at ​http://trac.edgewall.org/wiki/TracWorkflow. I use the second one with 'accepted', which means

• new = task created, maybe an owner already suggested
• assigned = actual work on task still not started, but owner is planned
• accepted = actual work on task by a certain owner has begun.
• testing = optional state after 'accepted', after actual work it's necessary that another worker of the test department works on it but this is another type of work we want to clarify by a different ticket state
• closed = all types of work have finished

Tickets can many weeks exist without work on it. After that someone switches to 'accepted' and spends a day of work in state 'accepted' before leaving that state again, and this is what I've called "done activities" in this ticket's description. "Done activities" is different to "planned activities".

It's not right if you say that state 'closed' is always the end of the tracked work, I suppose it's rather the probably earlier transition from 'accepted' to any other state which may be 'testing' or 'closed', although actually the time of testing is somehow also work time but need to be displayed in a different colour here (because the owner will change).

So after all, to represent what we understand as the term *work*, it's necessary to define when work starts and ends. I would need to configure it with

1. actual work
   • work_start[type1]=="when state 'accepted' begins" and
   • work_end[type1]=="when leaving state 'accepted'", and also
2. work on testing
   • work_start[type2]=="when state 'testing' begins" and
   • work_end[type2]=="when leaving state 'testing'".

Then the chart can be used as survey about both types of done work we're interested to track. Other people may set the to different states, so it's useful to define start and end states in the configuration.

Also take care that DONE work is different to PLANNED work. Actually, when looking at the chart some want to see what the plan is/was, other people want to see what the done work is, and likely compare. So I suggest to draw the chart like proposed here where the dark blue bars are times between work_start and work_end. The outer rectangle shows the planned ticket time range, the cyan part of the rectangle displays degree of fulfilment in percent.

Pay attention to not mix what plan and reality is, it would make the chart useless then. Everything must serve the reason why people look at this gantt chart:

1. read the plan
2. read what has happened (and compare with the plan)

[Chris Nelson]

Replying to falkb:

Well, these are just my thoughts about the fact that it's not sufficient to simply use transitions to or from states 'new' and 'closed':

Replying to ChrisNelson:

Similarly, work on the ticket begins on the first transition from new to any other status.

No, not 'new' to any other.

There are several workflows at ​http://trac.edgewall.org/wiki/TracWorkflow. I use the second one with 'accepted', which means

• new = task created, maybe an owner already suggested
• assigned = actual work on task still not started, but owner is planned
• accepted = actual work on task by a certain owner has begun.
• testing = optional state after 'accepted', after actual work it's necessary that another worker of the test department works on it but this is another type of work we want to clarify by a different ticket state
• closed = all types of work have finished

Tickets can many weeks exist without work on it. After that someone switches to 'accepted' and spends a day of work in state 'accepted' before leaving that state again, and this is what I've called "done activities" in this ticket's description. "Done activities" is different to "planned activities".

It's not right if you say that state 'closed' is always the end of the tracked work, I suppose it's rather the probably earlier transition from 'accepted' to any other state which may be 'testing' or 'closed', although actually the time of testing is somehow also work time but need to be displayed in a different colour here (because the owner will change).

So after all, to represent what we understand as the term *work*, it's necessary to define when work starts and ends. I would need to configure it with

1. actual work
   • work_start[type1]=="when state 'accepted' begins" and
   • work_end[type1]=="when leaving state 'accepted'", and also
2. work on testing
   • work_start[type2]=="when state 'testing' begins" and
   • work_end[type2]=="when leaving state 'testing'".

Then the chart can be used as survey about both types of done work we're interested to track. Other people may set the to different states, so it's useful to define start and end states in the configuration.

Also take care that DONE work is different to PLANNED work. Actually, when looking at the chart some want to see what the plan is/was, other people want to see what the done work is, and likely compare. So I suggest to draw the chart like proposed here where the dark blue bars are times between work_start and work_end. The outer rectangle shows the planned ticket time range, the cyan part of the rectangle displays degree of fulfilment in percent.

Pay attention to not mix what plan and reality is, it would make the chart useless then. Everything must serve the reason why people look at this gantt chart:

1. read the plan
2. read what has happened (and compare with the plan)

[Chris Nelson]

Replying to falkb:

Well, these are just my thoughts about the fact that it's not sufficient to simply use transitions to or from states 'new' and 'closed':

Replying to ChrisNelson:

Similarly, work on the ticket begins on the first transition from new to any other status.

No, not 'new' to any other.

There are several workflows at ​http://trac.edgewall.org/wiki/TracWorkflow. I use the second one

We have 8 custom, type-specific workflows for tickets!

with 'accepted', which means

• new = task created, maybe an owner already suggested
• assigned = actual work on task still not started, but owner is planned
• accepted = actual work on task by a certain owner has begun.
• testing = optional state after 'accepted', after actual work it's necessary that another worker of the test department works on it but this is another type of work we want to clarify by a different ticket state
• closed = all types of work have finished

Tickets can many weeks exist without work on it. After that someone switches to 'accepted' and spends a day of work in state 'accepted' before leaving that state again, and this is what I've called "done activities" in this ticket's description. "Done activities" is different to "planned activities".

So, a tickets is "active" (being worked on) when it enters "accepted"?

It's not right if you say that state 'closed' is always the end of the tracked work, I suppose it's rather the probably earlier transition from 'accepted' to any other state which may be 'testing' or 'closed', although actually the time of testing is somehow also work time but need to be displayed in a different colour here (because the owner will change).

Well, testing is work but I suppose it depends on how you track your work.

So after all, to represent what we understand as the term *work*, it's necessary to define when work starts and ends. I would need to configure it with

1. actual work
   • work_start[type1]=="when state 'accepted' begins" and
   • work_end[type1]=="when leaving state 'accepted'", and also
2. work on testing
   • work_start[type2]=="when state 'testing' begins" and
   • work_end[type2]=="when leaving state 'testing'".

Then the chart can be used as survey about both types of done work we're interested to track. Other people may set the to different states, so it's useful to define start and end states in the configuration.

Oy! Per-type states is more than I want to sign up for right now.

Also take care that DONE work is different to PLANNED work. Actually, when looking at the chart some want to see what the plan is/was, other people want to see what the done work is, and likely compare. So I suggest to draw the chart like proposed here where the dark blue bars are times between work_start and work_end. The outer rectangle shows the planned ticket time range, the cyan part of the rectangle displays degree of fulfilment in percent.

Ultimately -- likely quite far in the future -- I'd like to be able to show plan vs. actual on the chart. I've considered adding a "effective=<date>" option to the TracPM query that searches ticket change history and tells you what the status, estimate, etc. were on that date. If you did two queries like that with different dates (start of project and now, or whatever) you'd have the data to show the plan vs. actual. Getting the JS to do that is another, larger chore.

Pay attention to not mix what plan and reality is, it would make the chart useless then. Everything must serve the reason why people look at this gantt chart:

1. read the plan
2. read what has happened (and compare with the plan)

My short-term goal is to show what is, not what was planned.

It sounds like a reasonable start is to have a configurable list of statuses for "work_begun" and "work_done" then entering a work_begun status sets the start date and entering a work_done status sets the finish date.

[falkb]

Replying to ChrisNelson:

So, a tickets is "active" (being worked on) when it enters "accepted"?

yes, at least for my workflow

Well, testing is work but I suppose it depends on how you track your work.

I want to separate programming work and test work since both are different departments.

Ultimately -- likely quite far in the future -- I'd like to be able to show plan vs. actual on the chart. I've considered adding a "effective=<date>" option to the TracPM query that searches ticket change history and tells you what the status, estimate, etc. were on that date. If you did two queries like that with different dates (start of project and now, or whatever) you'd have the data to show the plan vs. actual.

...

My short-term goal is to show what is, not what was planned.

At present, the gantt chart is already displayed at a time when all tickets are freshly new, and then it's like a schedule, and if the milestone has been finished, it's a chart of what has happened. The problem is the time in the middle of a project when people are confused what actually still just is planned and what already is the done work, a main topic I noticed when asking people about your gantt chart.

It sounds like a reasonable start is to have a configurable list of statuses for "work_begun" and "work_done" then entering a work_begun status sets the start date and entering a work_done status sets the finish date.

Sounds promising

[Chris Nelson]

Replying to falkb:

Replying to ChrisNelson:

So, a tickets is "active" (being worked on) when it enters "accepted"?

yes, at least for my workflow

Well, testing is work but I suppose it depends on how you track your work.

I want to separate programming work and test work since both are different departments.

I'd do that with different tickets (one for dev, which completes and unblocks another for test) but that's just me.

...

My short-term goal is to show what is, not what was planned.

At present, the gantt chart is already displayed at a time when all tickets are freshly new, and then it's like a schedule, and if the milestone has been finished, it's a chart of what has happened. The problem is the time in the middle of a project when people are confused what actually still just is planned and what already is the done work, a main topic I noticed when asking people about your gantt chart.

Surely a different ticket from this one but what if I added configurable phases as additional PM-specific metadata. You could say "phase new is new and assigned, phase development is accepted, phase testing is ..., phase done is closed" then invoke the chart with "colorby=phase".

...

[falkb]

Replying to ChrisNelson:

Surely a different ticket from this one but what if I added configurable phases as additional PM-specific metadata. You could say "phase new is new and assigned, phase development is accepted, phase testing is ..., phase done is closed" then invoke the chart with "colorby=phase".

Yes, sounds good

[hut]

Hi,

Any news?

[uros@…]

I do vote for this feature, without actual presentation I do not find it that useful as it could be --- since for planning (and tracking) there are other tools such as www.TaskJuggler.org, which engine could also be integrated with the trac.

Where ticket starts date should be taken from accept and where it ends from: close.

In that way the the diagram could represent the actual tracking state, while start/end dates propose planned dates. So at the end we can have a good comparison over planned vs. actual progress (i.e. as in percentage actual duration/planned duration).

Testing and other possible states may also many times be assigned to other person(s), so possibly such states could be drawn as sub-tickets with dependency flow.

[anonymous]

Replying to uros@…:

I do vote for this feature, without actual presentation I do not find it that useful as it could be --- since for planning (and tracking) there are other tools such as www.TaskJuggler.org, which engine could also be integrated with the trac.

Where ticket starts date should be taken from accept and where it ends from: close.

In that way the the diagram could represent the actual tracking state, while start/end dates propose planned dates. So at the end we can have a good comparison over planned vs. actual progress (i.e. as in percentage actual duration/planned duration).

Testing and other possible states may also many times be assigned to other person(s), so possibly such states could be drawn as sub-tickets with dependency flow.

Like_this++

[uros@…]

I found a easy solution for integration with TaskJuggler (www.taskJuggler.org), in which tickets from TRAC are included.

Now I need to set back .start and .finish dates as calculated by the TaskJuggler. Do you maybe know any hint, how to do that?