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 <erickerick...@gmail.com> 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 > <casstarg...@gmail.com> wrote: >> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <ste...@mathe.is> 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
