Bugzilla – Full Text Bug Listing
| Summary: | [activity] support export of task planning and timing data | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Marko Asplund <marko.asplund> |
| Component: | Mylyn | Assignee: | Mik Kersten <mik.kersten> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | javadev, mjmeijer, robert.elves, roland |
| Version: | dev | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Marko Asplund
This is currently out of scope for Mylyn, but I'll leave it open in case anyone is interested in such a contribution. Although notably we have to be careful to extend the scope of Mylyn to this sort of planning and time tracking facility because it is a huge space and we would need to ensure that there were sufficient resources available to support it. What if the scope of this enhancement would be narrowed down to a point where it would allow do-it-yourself power-users to generate time sheets? Mylyn could e.g. simply allow users to export time usage data in a format understood by popular spreadsheet software (e.g. CSV)? Spreadsheet software or other reporting tools (e.g. BIRT) could then be used to actually generate the report. The export file should have detailed data about each time sheet entry including task category to enable rolling up to "project" level. It would also be nice to provide a public API for doing the export to allow automating the report generation process. Marko: that sounds like a good approach. Do you have links to a standardized format of this sort? I'm not aware of any data format standards by time tracking software but I'm not an expert on the subject so one might still exist. However, I would prefer a format that can be directly manipulated using spreadsheet software so that the data could be manipulated also without doing any coding. For this reason I think CSV would be a good format. Mik, just coma delimited list: category/query, task, project, resource, time, etc. Though special data provider for BIRT could be more convenient to deal with. I agree with a proposal in comment #5 that a generic data source implementation (DTP?) would go much beyond a simple exported CSV file. With CSV there is always a question of amount of information that gets exported - different people have different reporting needs and what is sufficient for one might be lacking for another... With a Mylyn Datasource implementation, people can craft their own reports either by just making arbitrary queries (I'm sorry, if I'm talking nonsense here - I've only had a casual brush with DTP as an SQL database user so far) against it (saving results to CSV if that is what they want to do) or using BIRT for creating full fledged reports... I'd say - expose the whole data model in this datasource and "let a hundred reports bloom"... The data source implementation sounds like it could be a good approach, as long as it does not add additional dependencies to Mylyn. If it does, we could still consider doing it as an optional feature, or having an extension support this. I want to be up-front about a strong bias that I have. Mylyn captures a lot of data about the way that we work in order to make it easier for us to track our own work. If implemented in the wrong way, or applied in the wrong kind of work environment, this kind of data can be misused. As such, I want to make sure that whatever we consider supporting in terms of additional reporting facilities is designed to empower the programmer and make it easier for them to communicate their activity. There are ways of implementing these facilities that would encourage micromanagement and misuse rather than empowerment. In the end this could mean having rules as simple as "don't export the programmer's activity without their explicit acknowledgment, in case timing is innacurate, etc". (In reply to comment #7) > The data source implementation sounds like it could be a good approach, as long > as it does not add additional dependencies to Mylyn. If it does, we could > still consider doing it as an optional feature, or having an extension support > this. My first guess is that it would probably add dependency on datatools, but that feature should be implemented in it's own plug-in and thus the dependency would be isolated to that plug-in only. I would assume that if done properly, this plug-in itself should only depend on core Mylyn and datatools apis and the rest of Mylyn should not require any new dependencies (or indeed not depend on the new data source plug-in either) > If implemented in the wrong way, or applied in the wrong kind of work > environment, this kind of data can be misused. There is always that "threat", as the data is already there and if really needed, any kind of abusive and misused data could be collected. However, I don't think Mylyn api should make the decision or enforce restrictions on the way the data is used. That is the sole responsibility of the user of the tool. Anyone with enough technical skills and determination can shoot themselves in the foot no matter what you do. Bad things will happen to people who are determined to misuse the tools and there is nothing we can do about it short of warning them about it... What I am voting here for is to give people enough data in a well structured form they can easily understand so that they could find many creative and useful applications for it... An article by Joels Spolsky (http://joelonsoftware.com/items/2007/10/26.html) describes, for example one possible, really useful way to use the data that could be made available with Mylyn Data source that goes far beyond merely being a time tracking report... Eclipsetimeline seems to me to be a possible starting point http://code.google.com/p/eclipsetimeline/ Tasktop also provides Time Tracking and export facilities: http://tasktop.com/products/eclipse/ Tracking and exporting time is something that's currently out of the scope of Mylyn, because it requires considerable UI to make usable (e.g., to adjust your timings, etc). |