26/05/05
Should Mantis support time tracking? |
The issue of time tracking support in Mantis has been raised several times before. There have been several patches and discussions about it. However, so far the feature has not made its way into Mantis source code.
David Newcomb has contributed a patch that is updated to integrate with Mantis 1.0.0a2 which is our latest release. I haven't reviewed the implementation of the patch, but I have to admit that I like the way the patch is "campained" and presented 
. Thanks David for that.
Based on the demo installation, the patch provides the following functionality:
- Ability to add a note with an associated duration of time.
- Ability to generate a report within the issue view page, which includes the total time spent by each user on the currently open issue.
- Ability to generate a billing report for all issues of the current project, and within each issue the total times for all the users who worked on it. This report all accepts the billing rate and shows the sums in the report.
My comments with regards to this particular implementation are:
- Consider using the term "Time Tracking" rather than "Time Taken".
- It would be useful to make the billing report work on the issues matching the current filter. This will allow generating billing reports based on a certain release, a certain state, or issues belonging to a certain customer. The date range for the time spent on the job will then act as a second level filter.
- It would be nice to add a report which shows the hours spent by a developer on all issues matching the current filtering and the report date range. This is useful to generate a developer weekly report and make sure that he generated the required billable hours.
- I believe it is critical to have the billing report formatted in a way that is printer friendly. Hence, I suggest a print/screen format, similar to other views/reports that we have.
- Should consider a compact format for the case where only one person worked on the issue.
- The time duration entered with the notes accepts negative duration. Is this intentional?
- In the screen version of the billing report, the issue ids should link back to the issue view pages.
- The currency for the billing rate should be customizable. Similar to the sponorship currency.
- I would assume that the billing rate is generally dependent on the developer (or users who spend time on the issue), the customer, and the project. Hence, a general flat rate is typically not good enough. To make things simple, I would recommend implementing a custom function which returns an hourly rate when given a user_id, issue_id. We can then have a flat rate that is used when this method returns -1. In this case, the default implementation for the custom function should return -1.
- At the moment, there is no way for the user to enter back dated notes to reflect work that was done in the past. The system assumes that the users will enter their ours daily.
- Document the database changes on the patch description page
That's all for now, as mentioned before this is based on reviewing a demo of the feature, the code is not reviewed yet. I will have to look at the following before making a final decision regarding including this in Mantis:
- Feedback from core development team.
- Feedback on this post and on the mailing list.
- Previous discussions, patches, and daily report implementation.
- Review the code for this patch.
Comments:
Comment from: John Cole [Visitor]
I'm evaluating this patch to see if it will allow us to move our customer support staff off of their issue tracker and use Mantis along with our development staff.
So far things look good, while I think this feature has a good ways to go before it is polished, it works (with small issues) and you can configure it to off so it doesn't impact regular use.
I'd like to see it become part of the main tree, even if it is off by default and marked experimental. That would really aid in development of this feature and get some good feed back from testers.
While I agree with all of Victors comments, I don't think all of those need to be implemented before it's included in the main code tree.
So far things look good, while I think this feature has a good ways to go before it is polished, it works (with small issues) and you can configure it to off so it doesn't impact regular use.
I'd like to see it become part of the main tree, even if it is off by default and marked experimental. That would really aid in development of this feature and get some good feed back from testers.
While I agree with all of Victors comments, I don't think all of those need to be implemented before it's included in the main code tree.
26/05/05 @ 04:36
Comment from: David Newcomb [Visitor] · http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken.html
1. "Time Tracking" rather than "Time Taken".
Fair enough!
2 & 3. Current filter
Ok - my next release
4. Print Screen for report
Ok - good idea. I was more thinking of adding them to the export in excel,
export in word formats, etc then the user can format it themselves.
5. Compact format
This is a variation of 2&3
6. -ve duration
Bug! I'll fix for my next release.
7. Issue link
I have wanted to do this but could not find a suitable command to do it
without creating another sql query. Maybe it's different in 1.0.0 - I'll
check.
8. Currency
Fair enough - next release
9. Custom rate
Already started to think about this. It is in my release notes as a future
enhancement.
10. Entering hours
In order to get to the point of entering a bugnote an amount of work would
have been done. If you spent 4 full days on it then 4 * 7 = 28 hours. Enter 28:00 in the time taken field. It is not nessacery to do it daily.
11. Document the db changes
So changes in the Configuration of my release notes at:
http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken.html
Would I be expected to do all the changes before it can be accepted, or
can I define a roadmap and introduce them gradually. It's taken quite
a bit of time to get this far, and I don't really want to spend all
my time merging between releases.
Fair enough!
2 & 3. Current filter
Ok - my next release
4. Print Screen for report
Ok - good idea. I was more thinking of adding them to the export in excel,
export in word formats, etc then the user can format it themselves.
5. Compact format
This is a variation of 2&3
6. -ve duration
Bug! I'll fix for my next release.
7. Issue link
I have wanted to do this but could not find a suitable command to do it
without creating another sql query. Maybe it's different in 1.0.0 - I'll
check.
8. Currency
Fair enough - next release
9. Custom rate
Already started to think about this. It is in my release notes as a future
enhancement.
10. Entering hours
In order to get to the point of entering a bugnote an amount of work would
have been done. If you spent 4 full days on it then 4 * 7 = 28 hours. Enter 28:00 in the time taken field. It is not nessacery to do it daily.
11. Document the db changes
So changes in the Configuration of my release notes at:
http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken.html
Would I be expected to do all the changes before it can be accepted, or
can I define a roadmap and introduce them gradually. It's taken quite
a bit of time to get this far, and I don't really want to spend all
my time merging between releases.
26/05/05 @ 04:38
Comment from: Dennis Spaag [Visitor] · http://www.gorillapolymedia.com
I think this functionality would be absolutely great to have. It is the main comment made by our PM. Perhaps for 1.0 if it can be made solid enough or as something that can be turned on/off and flagged as experimental. On the other hand, I am interested in seeing a 1.0 release asap. Wouldn't want this to be the reason for a delay. Thanks for asking.
26/05/05 @ 08:09
Comment from: Dennis Spaag [Visitor] · http://www.gorillapolymedia.com
What is the username/password for the demo?
26/05/05 @ 08:11
Comment from: David Newcomb [Visitor] · http://www.bigsoft.co.uk/projects/mantis/mantis-1.0.0a2-time_taken.html
Additional comments can be found at: http://bugs.mantisbt.org/view.php?id=4428
There are 2 users to play with:
joebloggs (for the uk people)
johndoe (for the us people)
The passwords are the same as the usernames.
26/05/05 @ 11:15
Comment from: OERNii [Visitor]
- a total sum if partial times per bug could be made
- a total sum of selected bugs could be made (filter, ID enumeration per select box, ...)
- a total sum of selected bugs could be made (filter, ID enumeration per select box, ...)
26/05/05 @ 17:01
Comment from: Marco [Visitor] · http://www.emmedipi.it
Would be very helpfull.
Also would be interesting to be able to measure the percentage of issues, that meet the time fixing defined for a specific priority
Also would be interesting to be able to measure the percentage of issues, that meet the time fixing defined for a specific priority
27/05/05 @ 00:51
Comment from: Steve Magruder [Visitor] · http://www.stevemagruder.com
Yes, Mantis should definitely support time tracking, as I'm certain I will use it, and I believe Mantis' profile will rise quite a bit with this feature. That said, it should be implemented as an optional feature turned on in the config file.
If this feature isn't "complete" upon release of Mantis 1.0, just note with a warning somewhere that it's "alpha"... another good reason to make it optional.
If this feature isn't "complete" upon release of Mantis 1.0, just note with a warning somewhere that it's "alpha"... another good reason to make it optional.
27/05/05 @ 04:15
Comment from: Glenn Henshaw (thraxisp) [Visitor]
I agree with Victor's comments, with the exception of 8 and 9.
I think that we should concentrate on gathering the information and reporting it. Export of the details to an external billing system is a necessary part of the system. I would avoid adding too much code relating to individual costs and related detais. A custom function to calculate costs would probably be the best way to do this.
I think that we should concentrate on gathering the information and reporting it. Export of the details to an external billing system is a necessary part of the system. I would avoid adding too much code relating to individual costs and related detais. A custom function to calculate costs would probably be the best way to do this.
27/05/05 @ 12:44
Comment from: Henno Täht [Visitor]
I manage a team of developers David's time tracking modification has proven to be so useful that I decided to start using it for production and switch from fixed rate salaries to time taken payment, since it's so easy to calculate the taken time now. It's certainly worth including to the main release, as there are probably a lot of Mantis users who could take advantage of the feature, once it's there and doesn't require much hassle to get it working.
Currently I copy-paste data to Excel and use Excel's Autofilter and Sum features to calculate salary for a developer. Surely, as the feature matures, I expect to see that functionality to be built-in.
Currently I copy-paste data to Excel and use Excel's Autofilter and Sum features to calculate salary for a developer. Surely, as the feature matures, I expect to see that functionality to be built-in.
07/06/05 @ 05:33
Comment from: Marc Gibert [Visitor]
I absolutely support this feature inside Mantis!
One question, is it possible to hide the field from certain profiles (observer, reportes, etc.)?
Thanks in advance.
One question, is it possible to hide the field from certain profiles (observer, reportes, etc.)?
Thanks in advance.
08/06/05 @ 07:14
Comment from: Damien [Visitor]
Personally I was simply going to add a custom field for handling this, though I must say it would be nice to be able to update it via notes. I look forward to the final decision on this.
08/06/05 @ 07:28
Comment from: Dirk Merkel [Visitor]
Time tracking is the most important feature I would like to see in an upcoming release.
09/06/05 @ 07:21
Comment from: Shawn Evans [Visitor]
I think time tracking is something that is important for billing as well as tracking, measuring CMMI metrics. I would like to see there be a way for a user to open the bug he is working on, check it as currently being worked on and require him to close it when he is finished working on it for the day (or have a automatic closing at a specified close of business time). If the user has multiple issues check as currently working, then the time gets divided between them evenly.
14/06/05 @ 02:52
Comment from: Cas [Visitor] · http://www.nuy.info
I do support the feature of time-tracking, just wonder if it needs to be part of Mantis itself.
One of the things i did, was to create a bridge between Mantis and Timesheet, the latter having most of all the functionality needed.
This way, we could have the best of both worlds.
If you are interested, I can make this add-on available. Just drop me a note on my home-site.
One of the things i did, was to create a bridge between Mantis and Timesheet, the latter having most of all the functionality needed.
This way, we could have the best of both worlds.
If you are interested, I can make this add-on available. Just drop me a note on my home-site.
14/06/05 @ 04:31
Comment from: KO [Visitor]
Nice feature!
I would like to have 3 time fields:
-Budget
-ETC (Estimated Time to Completion)
-Worked hours
I would like to have 3 time fields:
-Budget
-ETC (Estimated Time to Completion)
-Worked hours
16/06/05 @ 08:20
Comment from: Mitch [Visitor]
I've been using time tracking patches from Phillipe (iirc) - it's been something that has held me off newer versions - time tracking is key - and with anything that is under development, the maintenance of a feature that is not "in the base code" is a big effort - when it's in the main tree - as something like this should be in my opinion - it will be much easier to finish off and much easier to keep current and to keep people who need it (like me) on the current code and active in the main project. Thanks!
16/06/05 @ 18:09
Comment from: Mitch [Visitor]
Concerning billing rates... Should have put this in my first note, but if I was going to reinvent the wheel myself... I'd heard that there were external lookup functions that could be used to populate task fields from external data?
Project / posting member MAY be a clue to the rate, and an external lookup is a good idea - BUT even if the lookup included category information, a single job might have two different types of work performed by the same person at different rates or tax statuses.
Consider a task: "Install replacement printer" - here in BC Canada, running a cable that enters the wall would be taxed one way, the configuration of the printer would be taxed another way.
My perfect world was to use a lookup to return a selection list, which would be saved with the task note and could be used for billing - the rate doesn't need to be stored on the note, but COULD be overridden on the note.
Just a crazy thought - it's very clear in my mind if it isn't here - thanks again!
Project / posting member MAY be a clue to the rate, and an external lookup is a good idea - BUT even if the lookup included category information, a single job might have two different types of work performed by the same person at different rates or tax statuses.
Consider a task: "Install replacement printer" - here in BC Canada, running a cable that enters the wall would be taxed one way, the configuration of the printer would be taxed another way.
My perfect world was to use a lookup to return a selection list, which would be saved with the task note and could be used for billing - the rate doesn't need to be stored on the note, but COULD be overridden on the note.
Just a crazy thought - it's very clear in my mind if it isn't here - thanks again!
17/06/05 @ 01:46
Comment from: Dimon [Visitor]
Also It would be nice some reports. Based on time tracking.
I have been looking on Mantis as an Requirements tracking, for a long time. But always stops because I need to see dynamic of implementation.
For example need report.
In first column filtered issues.
In first row selected time, or milestones, or builds.
And from it I can see a dynamic and on time implementation.
I have been looking on Mantis as an Requirements tracking, for a long time. But always stops because I need to see dynamic of implementation.
For example need report.
In first column filtered issues.
In first row selected time, or milestones, or builds.
And from it I can see a dynamic and on time implementation.
27/07/05 @ 01:25
Comment from: Lafriks [Visitor]
This feature is realy needed!
18/08/05 @ 00:55
Comment from: Dan [Visitor]
Time tracking is really a must for us. We're using mantis as bugtracking tool but recently we switched to use it to assign tasks. Will be much easier to have time tracking implemented. We developed a service to check for a custom field named Due Date and send notification emails if the task is not completed in time.
09/09/05 @ 06:05
Comment from: Stephan Borg [Visitor]
Most definitely - at least as an option that can be turned on and off.
We definitely need this feature (and am implementing it from the patches as we speak) - and also some form of reporting would be great too.
We definitely need this feature (and am implementing it from the patches as we speak) - and also some form of reporting would be great too.
10/11/05 @ 19:37
Comment from: Jan Miczaika [Visitor] · http://www.hitflip.de
I would definitely like to see this kind of functionality in mantis. It is one of the few features I am missing.
One note: I would not spend too much time implementing billing / rates etc. Most companies have processes in place for converting hours worked -> billing. I would simply make the data visualization and export as easy as possible.
One note: I would not spend too much time implementing billing / rates etc. Most companies have processes in place for converting hours worked -> billing. I would simply make the data visualization and export as easy as possible.
05/12/05 @ 08:04
Comment from: benbalbo [Member]
I found this page by searching google for "mantis time tracking" - clicking on a search result took me to a page on this site telling me the referrer was a spammer, and to tell you in the comments if I felt this was in error. So here I am, telling you it's probably an error.
Cheers
BB
Cheers
BB
28/08/06 @ 18:56 Comments are closed for this post.