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.

[Christopher Lenz]

#1079 has been marked as duplicate of this ticket.

[Christopher Lenz]

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.

[Christopher Lenz]

#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.

[Alec Thomas]

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.

[Alec Thomas]

Actually, it's due in 0.11.

[Emmanuel Blot]

#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.

[Emmanuel Blot]

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).

[Christian Boos]

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.

[Emmanuel Blot]

(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.

[Christian Boos]

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)

[anonymous]

I'd like to also request this. I think the omission of any form of time tracking on a task system is a big impediment to resource planning or accountability, and this is something that should be addressed in Trac ASAP.

[anonymous]

I agree that this feature is a must for my group. I recently installed the timingandestimationplugin 0.7.3 plug-in, but it lacks the integration that I need in order to see how we are progressing on our milestones. My developers take pride in creating time estimates for every trac ticket during our planning phase of the project in order to determine, which features we can include in each release. They have voiced several times that it is very difficult for them to track the accuracy of their initial estimates or give updates on how much effort remains. They would like this feature added to allow them to get more feedback on how long it actually takes to implement features in order to allow them to improve their accuracy of their future time estimates.

[FilipeCorreia]

Replying to 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).

Although I agree taking an issue-driven approach is much better, it is usually still needed to make everyone aware of an expected time-frame (by "everyone" I mean both the rest of the team, and whoever will benefit form the issue being solved).

[FilipeCorreia]

Any chance this may still be considered for 0.12?

[anonymous]

Make it simple, make it small, but make it happen!

[jburgess@…]

If Trac could store time estimates and aggregate them by milestone, etc. that would be a big plus for our dev shop.

[r.blum@…]

No, really, it's not spam. I just want off the CC list. Please let me pass today, Akismet…

[Christian Boos]

Damn! Someone escaped from our Akismet jail!

[Sebastian Heuchler <sheuchler@…>]

I think this should be of higher priority, but I'm not a team member so…

[Remy Blank]

#8476 has been closed as a duplicate.

[anonymous]

test

[tex]

I also really miss time estimation in trac. We use agilo for scrum for agile development, that integrates trac product. We need time estimation because scrum is all about correct prediction of tasks. If developers could compare their initial estimates with actual, this could be possible.

Plugins can be used for this but internal database structure, that uses ticket_change concept makes hard to make analitical queries. I understand that some users see trac as operational tool that does not need history support, but it would be really usefull.

So I agree with some other comments:

• make time tracking support (basic at first)

and I add:

• think about history support in tables in future verisions (current ticket_change is very awkward for queries)

[Christian Boos]

Replying to tex:

• think about history support in tables in future verisions (current ticket_change is very awkward for queries)

I couldn't agree more. Would you mind having a look at GenericTrac and give some feedback?

[sheuchler@…]

not using trac anymore. do i really have to type something to remove my cc?

[bobbysmith007@…]

Replying to cboos:

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.

I am the maintainer of ​TimingAndEstimationPlugin. While it would be imprudent to speak of my own code quality, I feel that this plugin is fairly stable, has been widely deployed, and successfully used against a number of database backends. (I have run it extensively under both sqlite and postgresql, and had reports of people running it under mysql). I have also been supporting this plugin (via trac hack tickets, rather than the mailing list) since the release of Trac 10 and plan to continue doing so into the foreseeable future. I just wanted to add that I would be willing to help support this plugin's inclusion into a standard plugins package, were there ever to be one.

That said, this plugin now has two major branches, one that supports per-field permissions (via extensive use of Genshi filtering based on work started at ​BlackMagicTicketTweaks), and one that is much simpler and closer to the original request of this ticket (providing a time and estimate field). I dont know what would happen if they were installed side by side, presumably if only one was enabled then it would work fine. However, which of these should be included by default is non-obvious, and including both by default seems like it would cause more confusion than it solves. Thus it seems likely that leaving this plugin out of the default install might still prove to be the best answer.

HTH,
Russ Tyndall
​bobbysmith007

[anonymous]

I'm setting up a new project environment for a programming team, and I would really like to use Trac to this purpose. But logging the time spent is a make-or-break point. I'll give the TimingandEstimationPlugin a shot, but if that isn't up to par we'll be looking at a different package.

I want to put my voice in with the plenty of others that request this be integrated as a standard feature (a plugin that is included in the core package would do great).

[Christian Boos]

#3941 was closed as duplicate (requesting time recording overview, a la ​XPlanner).

[Mikko Rantalainen <mikko.rantalainen@…>]

I think that Trac should not track hours by default. However, there's value in keeping a rough estimate of work required for an issue to be solved. I'd suggest a field similar to Severity that by default included things like "Trivial", "Simple", "Hard", "Nearly impossible". This would allow automatic scheduling of tickets (e.g. schedule trivial high priority tickets to be done before nearly impossible high priority tickets) and automatic estimated completion times (see PivotalTracker.com for a nice example, there's no need for counting hours).

The above should be combined with #886 or #31: a single ticket should be a master ticket with no work estimate or a child ticket simple enough not worth having a estimate for work hours.

[anonymous]

Is there a support for the simple time tracking upgrade for Trac 1.0.1?

Thanks

[bashan@…]

Is there a support for the simple time tracking upgrade for Trac 1.0.1?

Thanks

[bashan@…]

Hi,

Does trac is still an active project. I really need the time tracking feature and have a simple question:

Is there a support for the simple time tracking upgrade for Trac 1.0.1? Thanks

[Ryan J Ollos]

Replying to bashan@…:

Is there a support for the simple time tracking upgrade for Trac 1.0.1?

There is no direct support in Trac 1.0.1, that is why this ticket is still open. There may be plugins to satisfy your needs, please ask on the t:MailingList.

[franz.mayer@…]

Maybe the wiki page TimeTracking helps you. We use (and implemented) the ​BudgetingPlugin. The plugin works fine, but it's not a candidate for integrating into core.

But I agree with several commenters above, that time tracking is an essential need for a "Project Management" tool (as it is stated in ​trac logo).

[mike.mclarrens@…]

Also wondering where Trac is going to. See a lot of bugfixing but nobody really is implementing the wanted features… time stamps … projects

[anonymous]

This is quite sad, since it is a great project. I am still not so sure if I can run the latest diff here: ​http://steffenpingel.de/files/patches/trac/

if I have trac version 1.0.1

Can anyone help me with that?

[figaro]

This feature request is unlikey to be implemented in Trac core soon. There is a variety of Trac plugins available to track time and budget effort:

• ​th:tags/estimation
• ​th:tags/planning
• ​th:tags/timing

[Jordan Sanders]

Hi everyone, my team developed a free time tracker which is compatible with Trac. So now you can track your working time in Trac using TMetric.

You can start to use ​Trac time tracker already now.

Steps to start time tracking:

Register in TMetric and install ​browser extension which will capture all your working time and tasks in Trac.

If you have any questions please leave them ​here

[Christian Boos]

Replying to Jordan Sanders:

Hi everyone, my team developed a free time tracker which is compatible with Trac. So now you can track your working time in Trac using TMetric.

Hi Jordan,

Thanks for your interest in supporting Trac in your tool! Also, it would be nice if you mentioned in your documentation which versions of Trac are known to be compatible (0.12, 1.0, "pretty-soon-to-be-released"-1.2).

[Jordan Sanders]

We tested our Time Tracker for Trac on 1.0 version and it worked nice but it should work also on all versions beginning from 0.11.

[Ryan J Ollos]

I agree with comment:2. We struggle with maintaining Trac, let alone adding advanced features like time tracking, which can be implemented with plugins.