Its all down to the design of the query. Personally im not familiar with the issue tracking db but if you examine any access form or report there are always two elements.
One is the the datasource... the query, how you get the data you want
Two is the layout.... the presentation, how you display/consume the data
There may be other elements such as parameters that limit what data is actually shown (think of them as switches). You could have a generic report and supply parameters to the report for a date range. Thats often done as a parameter added to the openreport macro. You can also do it as part of a query, but always means you must supply a value or the query will fail. The more sophisticated, more complex, more tweakable approach is to pass values between reports and forms.
For now look at the design of your existing reports
Understand how the report is laid out, understand what filters are
Look at the base query
Understand what where clauses in queries are and can do for you
In this sort of application its quite common to see people design say 6 or more reports, one each for open or closed issues for each of the 3 categories. But in reality you probably only need one report, one query, possibly one report for the 3 categories as they need a different sort order. An issues report and supply a parameter or filter to the report on openi g that limits that run of the report to say
Date range jan 2016 to march 2016
Assigned to 'cdubya'
I'd rather be riding on the Tiger 800 or the Norton