lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: [DISCUSS] JIRA maintenance and response times
Date Wed, 05 Oct 2016 14:56:41 GMT
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 <jwartes@whitepages.com>:
> 
> 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" <erickerickson@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
>    <casstargett@gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <stefan@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>> 
> 
>    ---------------------------------------------------------------------
>    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>    For additional commands, e-mail: dev-help@lucene.apache.org
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


Mime
View raw message