I think the first step should be about increasing visibility rather than enforcing transition rules (so the report and reminder part).
I've just been looking into Jira's reporting and it is quite flexible, but takes a while to wrap a mind around. Somebody digging in and coming up with great Solr-specific dashboards might be a way forward. People who are interested could then add them to their own screens. The next step would be to take those dashboards and run them centrally (e.g. on Amazon/Google AppEngine) with per-user information, to avoid those users needing to do the configuration. The next (or alternative) step would be to export JIRA data and do information crunching that the built-in reporting currently does not do. Reports I am specifically thinking about: *) Issues open for more than X days, in which the only activity (description+comments) comes from an original author. This would catch the issues nobody replied to yet *) Issues opened by a non-committer (to let people see the external community contribution and do triage/first-response) *) Issues where "I" made the last comment and X amount of time passed since - useful for "next action" reminders *) Issues older than X days that have '*.patch' attachment file (as opposed to random attachment) None of the above needs INFRA, as Jira will happily export up to ~200 issues with full details per API call. I am doing some real basic exploration about it right now. I also mentioned before, but perhaps not in this discussion, that it would be really nice to have some clarity/improvements on tagging the issues. For example, I want to tag all Admin UI issues, but not sure what the right tag would be. I could of course come up with one myself, but the joke about having one-more standard worries me. I would be happier to work within some sort of consent-oriented taxonomy. Though, this could be just my problem, because I am choosing to do lower-hanging fruits over multiple components rather than dark magic in selected few. > We already have the “Later” resolution (6 <https://issues.apache.org/jira/issues/?jql=project%20=%20SOLR%20AND%20resolution%20=%20Later> issues in Solr, 14 <https://issues.apache.org/jira/issues/?jql=project%20=%20LUCENE%20AND%20resolution%20=%20Later> in Lucene). I've just tried closing SOLR-373. I don't think it worked the way I thought it would work. It is now closed but still with the Resolution "later". UI did not give me an easy option to edit that as I close. I think "Later" may work better as the Status field (So, Opened, Reopened, Later, Closed), but I am not sure INFRA would want to change that. Regards, Alex. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 3 October 2016 at 03:23, Jan Høydahl <[email protected]> wrote: > 29. sep. 2016 kl. 19.35 skrev Cassandra Targett <[email protected]>: > > ... > > I fear a 7-day respond-or-close policy would frustrate people more. > Users would see their issues now closed instead of just ignored, and > if it gets a +1 from someone to stay open, it can still sit for the > next 5 years the same way as today. We need to take that idea a step > further. > > > My 7-day comment was not a proposal to auto-close, but as some kind > of internal goal of the community. > > What would I suggest instead? Not sure. One very small suggestion is > to add to Stefan's idea and send out a weekly mail about age of issues > - # of issues over 6 months, % increase/decrease, # of bugs with no > action in X days, # of improvements with patches that have no action > in X days. > > > Yes! A bigger ambition is to write a Python script that monitors and > enforces our agreed-upon rules and thresholds. If INFRA will give us > a user with API access for our projects we have ability to script just > about anything. > > In addition to generating a weekly mail report, the lucene_jira.py script > could also perform various actions proactively and automatically > > See sample state diagram: (https://dl.dropboxusercontent.com/u/ > 20080302/lucene_jira_states.png) > > The diagram suggests a custom automatic state transition by the script. > Issues older than 6m with no comments in 30d will receive a comment > “Issue seems to be inactive, will auto-close in 30d unless new activity. > If you want to close for now but be reminded in 12months, please close > manually with resolution=Later”. > The script will then tag the issue with a custom label “warn_close” which > it can use to decide whether to actually close after another 30d or not. > Likewise, we can monitor certain conditions such as new issues without > comments, issues with patch that may require committer attention etc. > Those issues being closed as “Later” will also be nagged every 12months > by the script, probably triggering either re-open or final close. > > Another idea is to have some kind of "parked" state in JIRA - like, > not Closed but not Open either. I'm not convinced that won't add to > the noise, but it might at least give us a better sense for ideas we > just haven't gotten to and issues we haven't really looked at yet. > > > We already have the “Later” resolution (6 > <https://issues.apache.org/jira/issues/?jql=project%20=%20SOLR%20AND%20resolution%20=%20Later> > issues > in Solr, 14 > <https://issues.apache.org/jira/issues/?jql=project%20=%20LUCENE%20AND%20resolution%20=%20Later> > in > Lucene). > > Jan >
