Opened 18 years ago
Last modified 3 years ago
#3156 new enhancement
Export Milestone to CSV
| Reported by: | anonymous | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | unscheduled |
| Component: | roadmap | Version: | 0.9.4 |
| Severity: | normal | Keywords: | convert export csv consider |
| Cc: | rafael@… | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Problem
There is no way to do postrelease ferensics.
Solution
The current reporting in trac is limited to ticket status snapshots. This is helpful as a status indicator and for milestone tracking. I didn't see postmotam analysis tools on the roadmap. Features that facilitate milestone analysis would greatly improve Trac's exposure to project managers, product managers and executives.
Including an export feature would get you 80% of the way. This would facilitate doing the analysis in excel while the integrated reporting tools are developed.
When exporting the data, ticket properties should be exported as a single line record. A record should be constituted as any change or addition to the ticket. So if the status changes and nothing else the csv record shoudl include all ticket properties including the status change.
| Ticket | Priority | description | Severity | Milestone |
| 1 | P1 | TEST Ticket | normal | 1.0 |
| 1 | P1 | New description | normal | 1.0 |
that would be exported as:
1,P1,TEST Ticket,normal,1.0 1,P1,New description,normal, 1.0
Attachments (0)
Change History (14)
comment:1 by , 18 years ago
| Milestone: | 0.9.6 |
|---|---|
| Severity: | major → normal |
| Type: | defect → enhancement |
comment:2 by , 18 years ago
Im sorry eblot, this is my first ticket i submit for you. What is an implementation/patch? How do i go about creating one to provide for you?
comment:3 by , 18 years ago
If you have some Python skills and can provide an implementation (the source code) of the feature you are requesting, it could help the developers to add such a feature to the main code. Note that there is no guarantee that the developers agree to add the feature to Trac.
Please do not assign an arbitraty milestone when you submit a ticket.
comment:4 by , 18 years ago
| Priority: | high → normal |
|---|---|
| Resolution: | → worksforme |
| Status: | new → closed |
You can export Queries or Reports in CSV format. Make either a Query or Report that contains the information you want and click on the link at the bottom to download as "Comma-delimited Text".
comment:5 by , 18 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
The request was about to get the ticket history in the .csv as well (one line per ticket change, see the above description).
comment:6 by , 18 years ago
eblot, I do not have the python skills to write the code needed. I have provided a use case and sudo code for this enhancement request. If I can do anything else please let me know. thank you.
use case
1. user queries ticket database 2. user exports all historic data with a provided link (similar to the comma-delimited text link) "historic csv" 3. user saves text and smiles in appreciation:-)
sudo code
the very loose sudo code provided is what should take place after the user clicks the "historic csv" link
0. detect user platform (Linux, Windows, OS X) 1. connect to the sqlite db specified in trac.ini 2. perform the user's query (use case set # 1) adding whatever sql is needed to include all historic data 3. aggregate the data separating each record.field data by ',' and each record by a newline and carriage return when needed by the user's platform 4. return the comma-delimited result back to the user.
sudo code
the loose sudo code provided here is what should take place after the user clicks the "historic comma-delimited" link
0. detect user platform (Linux, Windows, OS X) 1. connect to the sqlite db specified in trac.ini as the trac db 2. perform the user's query (use case set # 1) adding whatever sql is needed to include all historic data 3. agregate the data seperating each record.field data by ',' and each record by a newline and carage return when needed by the user's platform 4. return the comma-delimited result back to the user.
comment:7 by , 18 years ago
| Component: | report system → roadmap |
|---|---|
| Keywords: | convert added; to removed |
comment:8 by , 18 years ago
cboos: yes, I saw that this was about the ticket history. Reports don't have to return 1 row per ticket, you can include the ticket_change table and get a list of changes as well. If the only goal here is to export some of the ticket data as a CSV, a report should be able to get the necessary information.
However, I don't think we should ignore the original problem of collecting milestone statistics for analysis. Rafael, can you provide some details of the types of information you'd like to collect about the ticket? It may be possible plug some statistics into the milestone pages directly. The most immediate solution would be to write a WikiMacro that took a milestone name as an argument and output statistics. Then you could embed the macro in the description of each milestone. A plugin interface for this may be a better long-term solution, but the macro would help formulate some ideas for interesting statistics to collect.
comment:9 by , 18 years ago
mgood, a report with all ticket changes would work as long as it is exportable. In short mgood, my plan is to use the csv output in conjunction with pivot tables to find relationships between diff projects. The pivot table allows for dynamic analysis of the data. Each team will evaluate the data for point we can improve on the next time around.
The stats that we are going to look for first are as follows:
1. Open, Close, Verify Count: # of tickets opened and closed by each member of the team 2. Ticket Iteration Ratio: number of times a ticket was reopened by QA after it was closed per developer. (max, min, avg) 3. Priority Ratio: What is the ticket priority distribution per dev. 4. Priority Delta: How does the priority distribution / dev change over the course of the milestone fulfillment? 5. Severity Ratio: What is the severity distribution per dev? 6. Severity Delta: How does the severity distribution / dev change over the course of the milestone fulfillment? 7. Duplicate ticket total and per team member count (reporter and closer) 8. Invalid ticket total and per team member count (reporter and closer) 9. Wontfix ticket total and per team member count (reporter and closer) 10. Worksforme ticket total and per team member count (reporter and closer) 11. Max, Min, Avg ticket lifetime: length of time it took to close tickets. (Final close only) 12. Total Punt Count: number of tickets that were a part of the milestone but were pushed to a later release 13. Component count: total number of tickets logged against any component 14. Total Ticket logged count: total number of tickets logged for a milestone 15. Total Ticket closed count: total number of tickets that were closed against a milestone '''Note:''' Punt Count = total ticket logged - total ticket close }}
comment:10 by , 18 years ago
- Open, Close, Verify Count: # of tickets opened and closed by each member of the team 2. Ticket Iteration Ratio: number of times a ticket was reopened by QA after it was closed per developer. (max, min, avg) 3. Priority Ratio: What is the ticket priority distribution per dev.
- Priority Delta: How does the priority distribution / dev change over the course of the milestone fulfillment?
- Severity Ratio: What is the severity distribution per dev?
- Severity Delta: How does the severity distribution / dev change over the course of the milestone fulfillment?
- Duplicate ticket total and per team member count (reporter and closer) 8. Invalid ticket total and per team member count (reporter and closer) 9. Wontfix ticket total and per team member count (reporter and closer) 10. Worksforme ticket total and per team member count (reporter and closer)
- Max, Min, Avg ticket lifetime: length of time it took to close tickets. (Final close only) 12. Total Punt Count: number of tickets that were a part of the milestone but were pushed to a later release 13. Component count: total number of tickets logged against any component 14. Total Ticket logged count: total number of tickets logged for a milestone 15. Total Ticket closed count: total number of tickets that were closed against a milestone Note: Punt Count = total ticket logged - total ticket close
comment:11 by , 17 years ago
| Keywords: | consider added |
|---|---|
| Milestone: | → 2.0 |
Some interesting ideas discussed here, may be worth taking a look back at these after 1.0.
comment:13 by , 9 years ago
| Owner: | removed |
|---|---|
| Status: | reopened → new |
comment:14 by , 3 years ago
Trac is not originally conducive to interfacing with other tooling, such as Microsoft products.
Performing post-mortem analysis is likely best conducted in a plugin, because it offers the transparency needed and eliminates the need for reconciliations. Examples: TracTicketStatsPlugin, but would have to be amended to take into account milestones. Some older plugins with more substantial rework needed are StractisticsPlugin and TracMetrixPlugin.
Cleaning up this ticket: