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