Brainstorming ticket reports

One thing I’d like to work on is improve our reports on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. with the hope we can better manage the ticketticket Created for both bug reports and feature development on the bug tracker. queues. We currently have about 50 reports on Trac. Many of them were created in a push 5-6 years ago to build reports around keywords. A number of others are one-offs created in the last few years for specific use cases. In reality, few of these are ever used on a day-to-day basis.

I checked the access logs to get an idea of the most popular reports. Besides the first six reports (my favorite “home base” is report 6), they are report 16 (“Needs Patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.”), report 18 (“Blockers for Releases”), and report 21 (“Latest Tickets”).

What I’d like to do is brainstorm all sorts of new reports we should have. How can we make what we have better? I’ll then go to work about implementing them. Dream big — if the data’s there, I’ll figure out the gnarly SQL required. We can also think about how we can improve columns, grouping, ordering, etc. If you have a concept for a report but aren’t sure how we’d query for those tickets, toss the idea out there and maybe someone will add to it.

I’l probably design a new /report screen so it’s not just a list ordered by something random like when the report was created, and so we can highlight important reports, group similar reports together, and put less emphasis on some of the more specialized ones.

Here are some half-baked ideas, to start us off:

  • Open tickets without a response. Find all tickets where no one has commented, or where only the reporter has commented. This would create a punchlist of tickets to review. (Ideally, the report should always be empty.) The ability to group or filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. this by component would be helpful, for contributors who specialize in and want to take responsibility for different areas.
  • Report of “dead” tickets. Tickets that haven’t been modified in four years are ripe for action and/or closure. We should empty a report of this nature, then reduce it to 3.5 years, then 3 years, etc.
  • Good first bugs. A report of all tickets marked as a good first bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.. (None yet, as the keyword is new.) Next steps: How can we best identify these kinds of tickets?
  • Report of “untriaged” tickets. Our milestones have gotten out of hand, which is something we should discuss. Tickets should immediately leave “Awaiting Review” once they’ve been initially reviewed, but then not forgotten about if they are shifted to “Future Release”. Let’s figure out metrics for what makes a ticket “untriaged”. We could create a simple UIUI User interface to filter by component for a report like this. We currently have Tickets Awaiting Review which groups tickets by the “Version” they were reported against — maybe this is a good start.

What’s your idea?

#trac