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]
