Re: [DISCUSS] JIRA maintenance and response times

Progress update, I had pinged Mike McCandless and he - very kindly - implemented some new facets for the Jirasearch that - I think - would help for this discussion. The full list of changes is at http://blog.mikemccandless.com/2016/10/jiraseseach-20-dog-food-using-lucene-to.html The summary

Re: [DISCUSS] JIRA maintenance and response times

I was thinking about this some more last night, and since I’m in software, here’s the software I think I’d want: Create a list of Alerts, each of which know how to do two things: 1) Determine whether a given jira issue matches the alert 2) Determine an Alertee for a matching issue. One of

Re: [DISCUSS] JIRA maintenance and response times

I believe the first 3 dashboards can be done in JIRA itself. I have something similar, but unfortunately cannot share the dashboard (no permission it seems). The last one (breakdown of creation date? by year) is something that JIRA does not seem to be able to give. In terms of pulling data, I

Re: [DISCUSS] JIRA maintenance and response times

In terms of a report, I found a template that uses JIRA's API to import issues to a Google Sheet: http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet I made some modifications to the original and have shared it for public viewing:

Re: [DISCUSS] JIRA maintenance and response times

>From my reviews, I see a lot of issues where the discussion just petered out without clear handover of next action you would see in the support cases. So, I am not sure explicit flags would be something people use enough for this to work. But, as I believe I mentioned before, I think two basic

Re: [DISCUSS] JIRA maintenance and response times

Thanks for voicing your experience here. Hopefully more people find the discussion useful. > but unfortunately some also just rot, with the chances of them being useful > going down every day. I’d rather get a No. I agree with you, it is much better to get a +1 or -1 reply early than just

Re: [DISCUSS] JIRA maintenance and response times

I’m not a committer, but Solr is the first major open source project I’ve followed closely enough to get a feel for the actual community. The issues coming up in this thread have been rattling around in my head for at least the last year, and I’m absolutely thrilled to see this conversation. I

Re: [DISCUSS] JIRA maintenance and response times

Le lun. 3 oct. 2016 à 03:38, Alexandre Rafalovitch a écrit : > I think the first step should be about increasing visibility rather than > enforcing transition rules (so the report and reminder part). > +1 I like the idea of a weekly report to make it less likely for issues

Re: [DISCUSS] JIRA maintenance and response times

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,

Re: [DISCUSS] JIRA maintenance and response times

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

Re: [DISCUSS] JIRA maintenance and response times

> 29. sep. 2016 kl. 19.35 skrev Cassandra Targett : ... > 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

Re: [DISCUSS] JIRA maintenance and response times

I wonder how Mike McCandless extracts the information for http://jirasearch.mikemccandless.com/search.py?index=jira Because some of the reports discussed seem like they would be very easy against what he built. Or even if that extracted and transformed information could be available as a bulk

Re: [DISCUSS] JIRA maintenance and response times

I would love some new guidelines. One issue I don't see mentioned is a consistent way to tag the issues. We have tags, components, other things? And they are a bit all over the place. E.g. I don't know of an easy way to find all Admin UI issues. And I am not sure what to tag it even for the

Re: [DISCUSS] JIRA maintenance and response times

SOLR-629 was submitted with a patch eight years ago. I know it is useful, because I’ve implemented it on 1.3, 3.1, and 4.10. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Sep 29, 2016, at 11:32 AM, Erick Erickson wrote: >

Re: [DISCUSS] JIRA maintenance and response times

Big +1 to this statement: *** To me, the most urgent aspect of the problem is that Bugs are not getting verified and fixed as soon as possible, and non-committers (particularly) who take the time to create a patch for an improvement are not seeing their efforts acknowledged, let alone

Re: [DISCUSS] JIRA maintenance and response times

On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis wrote: > first idea about it: we could bring a script or something that collects once > a week information about all new issues and sends it to the dev-list? so get > a quick overview about what happend last week w/o too much

Re: [DISCUSS] JIRA maintenance and response times

On September 29, 2016 at 12:05:12 PM, Dawid Weiss (dawid.we...@gmail.com) wrote: > > As a project I feel it is unnecessary to have 2933 unresolved issues in > > JIRA. > > Some of these are old ideas, but remain valid (and are still > unresolved), Jan. This has been discussed in the past without

Re: [DISCUSS] JIRA maintenance and response times

> As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA. Some of these are old ideas, but remain valid (and are still unresolved), Jan. This has been discussed in the past without clear resolution. I will take a look at some of mine, but some of them do seem like they're

[DISCUSS] JIRA maintenance and response times

Hi, As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA. These issues have an *average* age of 1019 days (2 years 9 months)! Several reasons why I think this is bad * Looks bad on public stats * We lose oversight, important issues drown * Reporters do not get closure *