>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]
