Add basic time tracking

[joel@…]

I would like trac to have basic time reporting as a module.

The (logged in) user should be able to add that he/she worked for X hrs with something and add a short description of what. This time report could refer to a ticket and/or a changeset.

I am not familiar with the internals of trac, but I think that this could just be a new table in the DB and some basic templates/function to add and view data.

[BM]

I for one think that is a really good idea. Particularly if multiple changesets and tickets can be associated with a single time entry.

As a related aside I believe Trac now has enough features to warrant the ability to disable features that a particular install doesn't want, globally. Ignore me if it can already do this.

[daniel]

Time reporting is not within the scope of Trac.

You could use custom ticket properties to accomplish this, or optionally write an external utility to access the database.

[cmlenz]

#1079 has been marked as duplicate of this ticket.

[cmlenz]

Reopening this due to popular request. See also #1005.

The implementation of this feature depends on TracPluggableModules (in my opinion). See NewWorkflow and #869 for a proposal that would benefit from a general extension system as described in the pluggable modules proposal.

[anonymous]

I've done this very successfully using the custom fields. I use an initial estimate field, a current estimate (changed to reflect the updated idea of how long the ticket will take) and a cumulative time spent. I've even written a sync utility to allow us to synchronise with an xml gantt chart program.

I don't think this needs a plugin module or anything like that as that will only restrict the flexibility needed to support multiple different development processes.

The only change I'd like to see to trac to support this sort of thing is some additions to the types of custom fields to support Numerics - read only, cumulative, read/write etc.

[Matthew Good <trac matt-good net>]

#1290 has been marked as a duplicate of this ticket

[Stephen Kestle]

Just in case it gets missed, the only mandatory requirement for this to be reported on correctly would be initial time estimate. When the ticket is fixed, remaining time should be [able to be] set to 0 automatically.

Obviously more detailed operation needs to be supported (as above), but this very simple option should be supported as well.

[HumbertoDiogenes]

kisg posted a implementation of this feature in #1005.

[steffenp@…]

I have posted a summary of ways to add time tracking to Trac: http://projects.edgewall.com/trac/wiki/TimeTracking. It would be great if the page was used to collect more ideas and working solutions.

[trac@…]

I would propose that we use TracPluggableModules to accomplish this. It would basically involved adding a MilestoneStatisticsProvider extension point to the Milestone module. This extension would provide the milestone statistics, labels for the statistics and query links that find the tickets associated with the statistic. This would allow a plugin to provide an additional progress bar, with different units and different links to correspond to what those links mean.

Or is this too general? If the statistics for a milestone will only ever be some form of progress towards completion (in other words, this ticket is just a request for tickets to be weighted), then a simple configuration setting specifying which ticket field should be summed would suffice.

[cmlenz]

#2419 has been marked as duplicate of this ticket.

[vermersch@…]

Just finishing reading the book "Planning Xtreme programming". The only needed time tracking variables are :

• predicted time (day granularity)
• spent time (day granularity)

With this two data you can have :

developpers velocity

For example I always say it will take me 2 days to do this but in the

end it takes me 3 days. My velocity is 1.5 and next time I will multiply my predicted time by 1.5.

Due date respect

With the time spent in closed task + predicted time of active task. You

can calclulate the real progression and if due date will be respected. sorry for my ugly english

[ckramer]

I must say, this feature must be included in base Trac package.

We are using time tracking patch on big projects. In some way, Trac Time Tracking replaces MS Project, we don't need to dupicate tickets in MS Project just to track time there.

This feature must be included in base Trac package.

• This patch don't harm or alter Trac functionality
• It's pretty stable
• Tested over many projects
• Can be turned off if not needed

The only reason why it's not in base dstribution is someone's ambition to keep Trac "non-bloated with features".

Political reason stays in a way of developing a better product.

[fevzi]

I agree that this should be included in the base package

[anonymous]

Curious as to when this workflow is planned. Our organization is evaluating Trac vs. some tools that support eXtreme Programming stuff, and knowing the timeline for this would help us make a decision.

[athomas]

The WorkFlow branch is undergoing heavy development at the moment. The plugin system is already quite advanced and I believe could mostly accomplish what this ticket requires. Feel free to check it out and write a plugin.

Here's an outline of some of the things the plugin would need to provide:

1. ITicketFieldTypeProvider, providing a "time" field type.
2. ITicketFieldProvider providing the "time tracked".
3. Probably IEnvironmentSetupParticipant to add an extra table for storing the time logs.
4. Would also probably need to add a /timetracking URL via IRequestHandler. This would display all of the time logs. Ideally this would be inserted into the ticket page, but this will not be possible until Trac moves to the Kid templating engine (see milestone:0.11).
5. ITimelineEventProvider for showing the time logs in the timeline.

This sounds like a lot of work, but isn't actually too bad :).

WorkFlow is scheduled for integration in 0.12, but people are using it with some success already. Victims..errr...testers welcome.

[athomas]

Actually, it's due in 0.11.

[eblot]

#3188 has been marked as a duplicate.

[Sid Wiesner]

Support for time tracking was added in the TimingAndEstimation plugin available from Trac Hacks.

In addition, the TimeTracking page describes other approaches you can use to accomplish the requirements stated in this ticket.

These approaches seem to accomplish the original goal of this ticket, right?

[writetoalok+trac@…]

Time tracking is a useful feature. Don't see any reason why it should'nt be included in Trac core codebase. Also would like to see more relations between tickets (or tasks) apart from the Milestone grouping like in Bugzilla.

[eblot]

Replying to writetoalok+trac@gmail.com:

Time tracking is a useful feature. Don't see any reason why it should'nt be included in Trac core codebase.

It depends on how Trac is used, and who uses it. From a developer stand point, I don't see it as a core feature (personal opinion).

[cboos]

A few more duplicates, besides the one already mentioned above: #440, #560, #564, #838, #914, #2181 and #4512.

[anonymous]

Replying to eblot:

Replying to writetoalok+trac@gmail.com:

Time tracking is a useful feature. Don't see any reason why it should'nt be included in Trac core codebase.

It depends on how Trac is used, and who uses it. From a developer stand point, I don't see it as a core feature (personal opinion).

I am a developer too, and find it necessary to report where I spend my time. And it is also helpful to regulate myself to work on core problems, without being distracted too much by side issues. And tracking tasks without tracking time is like living in a dream without believing it could become anything real. Or it is like developing Chandler for the rest of your life.

[r.blum@…]

Sigh. There's a plugin to do this. What's the point of having it in the base package? If some people think they need it, and others think they don't, it's fairly clear it's optional, no?

[ingmar@…]

Replying to r.blum@gmx.net:

Sigh. There's a plugin to do this. What's the point of having it in the base package? If some people think they need it, and others think they don't, it's fairly clear it's optional, no?

With the same argument you can more one of Priority and Severity to a plugin. Some people think they serve identical purpose and use only one. I also find it very useful and having it in the core package makes it easier to setup and more people benefit from it. Anything that is only in a plugin will not be tried by a large fraction of the Trac users.

[anonymous]

Replying to ingmar@clarontech.com:

With the same argument you can more one of Priority and Severity to a plugin. Some people think they serve identical purpose and use only one. I also find it very useful and having it in the core package makes it easier to setup and more people benefit from it. Anything that is only in a plugin will not be tried by a large fraction of the Trac users.

Yeah, maybe, but the developers want to keep the Trac core small enough, not bloated with every single need or requested feature.

Trac needs to provide the extension points to enable such a plugin, but I don't think it should be part of Trac core.

[eblot]

(anonymous was me)

[anonymous]

What about adding to TimingAndEstimation? plugin the ability to show another % bar to the roadmap module.. This % bar would indicate how much time is left untill milestone's completition..

[anonymous]

Whether to add a feature to the base product should not be judged based on whether it makes the core "too big" where "too big" is a meaningless and arbitrary, personal limit.

Whether to add a feature should be judged based entirely on whether it is part of the core value proposition (the "identity") of the product, as defined by the people who own the product. If a feature contributes to the core value proposition, then it should be in the base product.

A project isn't very interesting unless there's an end goal that the project team is driving towards. A project isn't being managed unless at least one person is monitoring progress and driving the team towards that goal. The existing base Trac product cannot be used to determine how far, measured in time (not tickets), the team is away from its goals. That is the missing feature: to be able to monitor progress of a milestone and determine how far away, expressed in units of time, the team is away from completing a milestone. The simplest way to solve this is something like what the time-tracking patch does.

Today a plugin must be added, or the product patched, or a third-party project management tool must be used to provide this fundamental project management feature.

The Trac tagline is "Integrated SCM and Project Management". If the vision of the product is really to provide the project management component that you advertise, then you must have some capability to measure the time left on a milestone (in the base product) in order to claim real project management support. Otherwise the base product just groups tickets into buckets that you can add a date label to. The date fields might as well be text.

[cboos]

I've a mixed feeling about this topic. On one side, I hate time-tracking, so I feel comfortable with Trac's default model (issue driven, as opposed to schedule driven).

On the other side, this seems to be a frequent need for our users, so that we might consider bundling such a plugin as part of the default plugin library, provided the plugin meets a few criteria like decent code quality, maintainer's willingness to support its plugin, etc.

Such a default plugin library is a recurring discussion topic on the trac-dev mailing list, though not consensus has been reached yet.

[mbearden]

My company also would greatly appreciate time estimates (as from a plugin) to be used in weighting the progress bar of the road map items. The previous anonymous user said it very well:

The existing base Trac product cannot be used to determine how 
far, measured in time (not tickets), the team is away from its goals.

and yet tracking projects in time is almost all we care about at my company. Do you think my manager asks me how many "tickets" we have left to go until we complete an iteration? Nobody plans production in terms of tickets...as in "We can do 8 tickets per week/month" or "The next release will require 12 tickets of development resources." I find very surprising the resistance expressed on this discussion board to adding this MOST BASIC feature to Trac, as the very idea of "thinking in tickets" about planning and tracking releases makes no sense to the perspective of production and resource management. (Tickets are not resources...time is a resource.)

I actually "hacked" this into the Python code myself back when I was using version 0.10. Since upgrading to 0.11, I was disappointed to discover that I could not easily re-apply my hack (code was rearchitected in a big way) and I haven't yet had time to re-hack version 0.11. We now miss having road map progress bars that give a TIME-based estimate of progress and time remaining.

I hope that my adding my voice to the many others that have posted this request will help to keep attention on this need. I will encourage any others who happen to read this to express their opinions to the Trac development managers.

[anonymous]

Count me in as an interested person! Time tracking would be a really valuable feature to have. (currently I use trac for project management, time I have to track completely seperate, which can be a burden sometimes - keeping track and time tracking in sync requires quite some manual effort which could be greatly reduced by this feature)