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 relevant right now is that we can now ALSO filter issues by the last person who updated it as well as the time that passed since that last update. And - that was his idea - who actually committed within that issue. None of these were possible with Jira JQL queries, however smart. Which means I can run the queries such as: http://jirasearch.mikemccandless.com/search.py?chg=dds&text=&a1=updatedOld&a2=%3E+1+week+ago&page=0&searcher=938&sort=recentlyUpdated&format=list&id=r3zft095hlwr&dd=project%3ASolr&dd=status%3AOpen%2CReopened&dd=lastContributor%3AAlexandre+Rafalovitch&newText= (Opened/Reopened Solr issues in which the last comment was mine and it's been longer than a week) - which means follow-up time. Or http://jirasearch.mikemccandless.com/search.py?chg=dds&text=&a1=hasCommits&a2=0&page=0&searcher=938&sort=recentlyUpdated&format=list&id=qkprrewu1d2r&dd=project%3ASolr&dd=status%3AOpen%2CReopened&dd=allUsers%3AAlexandre+Rafalovitch&dd=updatedOld%3A%3E+3+months+ago&newText= (Discussions I participated in that has gone dark without outcome (commit) for more than 3 months.) I think that's a great step forward both for interactive exploration as well as for this specific discussion on whether something like that should be an automatic report for individuals. Because, as part of the upgrade, Mike also open-sourced the tools to download JIRAs into a form where we could run the tools, summary reports,visualizations, etc. Nothing is stopping us now but the consensus on what exactly the next step should be (the hard part, I know). Regards, Alex. ---- Solr Example reading group is starting November 2016, join us at http://j.mp/SolrERG On 5 October 2016 at 16:53, Jeff Wartes <[email protected]> wrote: > 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 Alexandre’s examples in this context: 1) If the issue hasn’t had an > update in a week, and the last update was by a committer, it’s a match. 2) > The committer with the last comment is the Alertee. > Another example: 1) If the issue has a patch file or a github pull request > comment, but isn’t assigned to anyone, it’s a match. 2) This dev mailing list > is the Alertee > > Every week, iterate through all unresolved issues, and give every Alert > definition the chance to gather the list of matching tickets. > Then: > 1. Dump each Alert’s list of issues on a web page someplace. Include diffs vs > the last run, so you can see if a given Alert’s list is growing over time. > 2. Get the distinct list of Alertee for all issues that matched any Alerts, > and send each Alertee one email with the list of issues mapped to that > Alertee, grouped by Alert type. > > So you give periodic reminders to exactly the people who should get them, and > you also have a place you can see this week’s status for everything. For > bonus points, people could squelch getting the email if it only contained > issues derived from certain Alerts. > > > On 10/5/16, 10:42 AM, "Alexandre Rafalovitch" <[email protected]> wrote: > > 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 was able to build an API to pull up to 200 > issues from JIRA at a time with full case information in the - as > Cassandra discovered - rather convoluted XML. So, it would not be too > hard to run several APIs and merge the results to get full export. And > then maybe run daily/weekly export and merge/override. Then, it is > pre-process and distribute. > > It is totally doable. We just need to firm up the business > requirements. What kind of reports people feel would be useful for > _them_ to be more proactive. I've listed my ideas earlier, but not > sure if they would be useful to others. > > Regards, > Alex. > P.s. Do we need a JIRA for this? > ---- > Newsletter and resources for Solr beginners and intermediates: > http://www.solr-start.com/ > > > On 6 October 2016 at 00:06, Cassandra Targett <[email protected]> > wrote: > > 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: > > > https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0 > > > > I was able to pull in issues with my JIRA login without asking INFRA, > > so I think committers at least already have permissions to use the > > JIRA API. > > > > The template Sheet was initially created to make a board with cards > > for planning, but I have removed those tabs and the script that > > generates the cards. So ignore anything about "story cards" that you > > might see in instructions or anywhere else. > > > > There are a few issues with the API output that makes the data a > > little difficult to work with. Most of the fields I wanted include a > > bunch of metadata JIRA uses for display. And the date field won't > > convert from a timestamp to a date. The date issue is the worst of > > these, for aging purposes, but there might be something we can do in > > the script that pulls the data to fix this. > > > > Despite that, it's still possible to make a simple report from this. > > I've added a tab "Stats" that shows some initial (easy) calculations - > > # of Issues by Type, # older than 2016 by types, # unassigned, a > > breakdown by year. > > > > Google's flavor of javascript (Google Apps Script) runs the sheet, so > > I think we could add to the main script, or add other scripts, if we > > want to. I know pretty close to zero javascript, however, so would > > need help there. > > > > JIRA can do a lot of this same stuff in its own dashboards (especially > > basic stuff), but that's very much opt-in by individual users. It > > sounds like some folks would prefer something pushed to the community. > > We could do a combination, however - I could take a stab at a shared > > dashboard people could opt into, and also send out a summary weekly > > based on a report generated somehow. > > > > I have no ego invested in the import-to-spreadsheet example I'm > > sharing here; if it won't work for helping us to stay on top of aging > > issues, I can toss it. It was just an option to explore since there is > > an easy-to-use template already out in the world. If we do think it > > will work, though, I can give edit permissions to the folks who want > > to help get it into shape. > > > > On Wed, Oct 5, 2016 at 11:24 AM, Alexandre Rafalovitch > > <[email protected]> wrote: > >> 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 reports may > >> make a difference: > >> 1) Case older than X days, where all comments are by the same author > >> (as in, nobody else looked at it yet) > >> 2) Case where "I" did the last response and that response is older > >> than X. This will help to restart the conversations where I said "what > >> do you think?" and the other person(s) did not reply, therefore > >> causing a long conversation lull. This will not help with "we are > >> waiting for issue Y", but perhaps that could be an edge case to code > >> around. > >> > >> Unfortunately, I don't think JIRA's JQL supports either of the > >> queries. I poked around a bit and don't see relevant fields/functions. > >> So, it would have to be a 3rd party app based on JIRA exports with > >> committers individually subscribing to receive the reports. > >> > >> Regards, > >> Alex. > >> P.s. If we can tell what flags are Solr specific, it would be great to > >> review those and perhaps remove all irrelevant ones. > >> > >> ---- > >> Newsletter and resources for Solr beginners and intermediates: > >> http://www.solr-start.com/ > >> > >> > >> On 5 October 2016 at 21:56, Jan Høydahl <[email protected]> wrote: > >>> 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 > >>> silence :) > >>> > >>> Anything to help call out issues that need attention would be greatly > >>> appreciated > >>> > >>> > >>> Today most people just add a comment “Can a committer please look at > this?”, > >>> and if it is still silent some time later there may be an email to > dev@ > >>> calling out for committer attention for SOLR-NNNN. > >>> > >>> If we get ourselves a dashboard, it would be nice to have a column > listing > >>> issues that are explicitly awaiting review. But how should that be > >>> populated? The proper JIRA way would be through a different Status > workflow, > >>> where an issue can be changed from OPEN —> NEEDS REVIEW. Or we could > agree > >>> on a label or even a “Flag” that can be filtered on. > >>> > >>> Speaking of flags, the SOLR Jira has two boolean flags: “Important” > (sic) > >>> and “Patch”. Should probably just delete them as they are not being > used.. > >>> > >>> -- > >>> Jan Høydahl, search solution architect > >>> Cominvent AS - www.cominvent.com > >>> > >>> 4. okt. 2016 kl. 23.02 skrev Jeff Wartes <[email protected]>: > >>> > >>> 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 > >>> nearly brought it up myself on couple of occasions, but I wasn’t sure > how > >>> much of this was common to all open source (volunteer-driven) > projects. > >>> > >>> I’ve filed Solr issues, some with patches, some of which have been > accepted. > >>> Some went a different way than I expected, which is fine, but > unfortunately > >>> some also just rot, with the chances of them being useful going down > every > >>> day. I’d rather get a No. > >>> > >>> There have been a few cases where I’ve worked on a patch after > discussing > >>> and getting a favorable opinion from a committer, but even that > doesn’t seem > >>> to offer any assurance that the work will ever be reviewed. > >>> > >>> And frankly, yes, this effects how I deal with Solr issues. Among > other > >>> things, it discourages me from contributing more work until I see > attention > >>> to the stuff I’ve already provided. > >>> > >>> Anything to help call out issues that need attention would be greatly > >>> appreciated, I think. I have a suspicion that the > Jira-notificaiton-firehose > >>> is the most common notification mechanism, and people generally just > look at > >>> whatever came out most recently there. Meaning, if something blew past > >>> unnoticed, it’s gone forever. > >>> > >>> > >>> > >>> On 9/29/16, 11:32 AM, "Erick Erickson" <[email protected]> > wrote: > >>> > >>> 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 reviewed or > >>> committed > >>> ************ > >>> > >>> This hits the nail on the head IMO. I wonder how many potential > >>> committers we've lost through inaction? Yonik's line about "you > >>> get to be a committer by acting like a committer" comes to mind. > >>> We have people "acting like committers" by submitting > >>> patches and the like then don't get back to them. > >>> > >>> Of course we all have our day jobs, limited time and at least > >>> some of us have these things called "lives". > >>> > >>> I'm not sure how to resolve the issue either. It can take > >>> significant time to even look at a patch and give any reasonable > >>> feedback.... > >>> > >>> I'm glad for the conversation too, just wish I had a magic cure. > >>> > >>> Erick > >>> > >>> > >>> On Thu, Sep 29, 2016 at 10:35 AM, Cassandra Targett > >>> <[email protected]> wrote: > >>> > >>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[email protected]> > 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 trouble? > >>> > >>> > >>> +1 to this idea - awareness of the problem is the first step to being > >>> able to change it. And I agree it is a problem. > >>> > >>> It's enough of a problem that at Lucidworks we have added it to our > >>> priority list for the next year. Consequently, I've spent quite a bit > >>> of time looking at old issues in the past couple of months. > >>> > >>> 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 reviewed or > >>> committed. I think this causes more bad impressions than someone's > >>> good idea for a new feature that doesn't get implemented. (BTW, Bugs > >>> alone make up 44% of all issues older than 6 months; Improvements are > >>> another 38% of old issues.) > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> Thanks for bringing this up, Jan. It's a necessary conversation to > have. > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
