I also agree with Alex regarding tagging the issues and perhaps if possible/known, tag the effort/complexity level (high, medium, easy or beginner/seasoned etc.) that new comers can also contribute. This may help to get the low-hanging fruits to get done quicker and close some of them.
Thanks, Susheel On Sun, Oct 2, 2016 at 9:38 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > 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 <jan....@cominvent.com> wrote: > >> 29. sep. 2016 kl. 19.35 skrev Cassandra Targett <casstarg...@gmail.com>: >> >> ... >> >> 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 >> > >
