Keeping track of time spent on an issue

for my issue tracking needs at my day job (http://www.cs.wisc.edu/condor), we'd like to start keeping track of how long we spend on a given issue. mostly, we'd use this for our internal development tasks, not so much the "helpdesk" style end-user support (though i could see us caring about time spent in those issues, too).

clearly, this is something a lot of issue tracking systems already support, and lots of people need this kind of functionality (though often in more corporate environments). however, i'm not sure we'd want anything like this in the issue queues for drupal.org (though i'm not really sure... i could potentially see it being useful, even there, though for different reasons). generally, i'm leaning away from wanting to have any of this functionality on drupal.org.

so, i see 3 possible approaches:

1. put this functionality directly into the project issue tracking module, but do it in such a way that it's easy to disable on a site-wide (or possibly even per-project) basis. there'd be a few extra columns in a few DB tables, and some UI elements that conditionally appear/disappear (e.g. some fields when replying to issues to indicate time spent, etc), and perhaps even another column in the issue summary pages. so, all the "plumbing" would be in the main module, the schema would be setup to handle it, but not every project's issues would actually display/use any of this stuff on sites (e.g. drupal.org) that don't want it.
2. put all this functionality into a standalone module (i'd include it in the same directory/project node/tarball with project_issue.module, but call it something like "issue_timetracker.module"). it'd have to setup its own DB tables to keep track of this stuff and it would hook_menu() and form_alter() itself into place. it'd be slightly less efficient (more JOINs, etc) and might be a little complicated to insert itself into all the places it might want to be than just doing it directly in the project_issue code, but it'd be trivial to disable it site wide (just don't install), and would probably keep the d.o folks (dries, killes, etc) happier to have this code in a separate module which they wouldn't have to install.
3. give up on drupal's issue tracking and use another tool that does this already (see http://groups.drupal.org/node/1047 for thoughts on that approach, and why i'd prefer not go that route).

here's a rough outline of how i see it working (this is basically how i'd want it to work for my needs, though some of this is overkill for the 1st iteration of an implementation):

• each issue has 2 new fields: "time estimate", "time spent"
• followups can alter either one (probably, i'd have the "time spent" field be per-comment, and the issue's value is just the total for all comments).
• i'd introduce permissions for:
  • "view issue times" (so you could set it up so that end-users don't see this stuff, but developers/support folks could)
  • "edit issue time estimate"
  • "edit issue time spent"

  (i'd keep the last 2 different so that, for example, a project lead/manager could be authorized to change the estimates, but normal developers could only add time spent -- probably overkill).

• there'd be some new views of the issue queue:
  • add columns to the regular issue queue listings (either single project or all projects views) to display these 2 values
  • view all issues for a given developer, w/ ability to sort by times
  • summary view of all developers, with a total value of "time left" for all of their open issues (e.g. estimate - time spent).

some open questions...

1. does anyone think time tracking would at all be useful on d.o itself?
2. is the additional complication + possible overhead of approach #2 worth it in terms of not adding more code that has to run on d.o?
3. would anyone else find this functionality helpful in their own usage of project + project_issue?
4. any suggestions for my rough outline above?

personally, i wouldn't really care that much about all of this, and it's not my own top-priority for drupal itself. however, it's a fairly urgent requirement for adopting drupal-based issue tracking at my work, which gives it an urgency of it's own...

feedback welcome!
thanks,
-derek