Re: [DISCUSS] JIRA maintenance and response times

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Dawid Weiss-2
> As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA.

Some of these are old ideas, but remain valid (and are still
unresolved), Jan. This has been discussed in the past without clear
resolution.

I will take a look at some of mine, but some of them do seem like
they're still valid (unless somebody steps up to solve them or we draw
the line that we never will):

https://issues.apache.org/jira/browse/LUCENE-5755

D.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Stefan Matheis-3
On September 29, 2016 at 12:05:12 PM, Dawid Weiss ([hidden email]) wrote:
> > As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA.
>  
> Some of these are old ideas, but remain valid (and are still
> unresolved), Jan. This has been discussed in the past without clear
> resolution.
>  

Which is absolutely fine - at least how i understand Jan’s suggestion. The point would probably be to revisit those from time to time and decide if they are still valid or perhaps already done as part of another ticket or something along the lines.


On September 29, 2016 at 11:53:37 AM, Jan Høydahl ([hidden email]) wrote:
> Furthermore the time to first response is not uncommonly 90 days or more!
> I think we should strive to have no newly opened issues older than 7 days
> without at least having one response, question, +1/-1 etc. Perhaps with
> the exception of issues created by the committers or assigned to someone?

I like it. I’m not even sure i’d make an expection for issues that are assigned to someone - especially new users tend to use JIRA in ways we probably are not aware of (including setting an estimate and stuff like that)


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?

-Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Cassandra Targett
On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Erick Erickson
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
<[hidden email]> wrote:

> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Walter Underwood
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
[hidden email]
http://observer.wunderwood.org/  (my blog)

On Sep 29, 2016, at 11:32 AM, Erick Erickson <[hidden email]> 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
<[hidden email]> wrote:
On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
In reply to this post by Dawid Weiss-2
I would love some new guidelines.

One issue I don't see mentioned is a consistent way to tag the issues.
We have tags, components, other things? And they are a bit all over
the place.

E.g. I don't know of an easy way to find all Admin UI issues. And I am
not sure what to tag it even for the issues I did find through other
means.

Regards,
   Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 29 September 2016 at 16:53, Jan Høydahl <[hidden email]> wrote:

> Hi,
>
> As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA.
> These issues have an *average* age of 1019 days (2 years 9 months)!
>
> Several reasons why I think this is bad
> * Looks bad on public stats
> * We lose oversight, important issues drown
> * Reporters do not get closure
> * New developers get discouraged
> * We cannot use JIRA stats/reports as goals for our community
>
> Furthermore the time to first response is not uncommonly 90 days or more!
> I think we should strive to have no newly opened issues older than 7 days
> without at least having one response, question, +1/-1 etc. Perhaps with
> the exception of issues created by the committers or assigned to someone?
>
>
> I know some community members earlier have disagreed and feel it is not
> important to have JIRA reflect importance/priorities. I mean, we do not use
> features like votes, IN PROGRESS status etc in any meaningful way today.
>
> As we’ve onboarded many new committers last few years and I’d like to hear
> if you’re all happy with our (sloppy) Jira maintenance or if it is time to
> draw some new guidelines?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
In reply to this post by Stefan Matheis-3
I wonder how Mike McCandless extracts the information for
http://jirasearch.mikemccandless.com/search.py?index=jira

Because some of the reports discussed seem like they would be very
easy against what he built.

Or even if that extracted and transformed information could be
available as a bulk download to play with instead of trying to wrestle
JIRA REST API.

Regards,
   Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 29 September 2016 at 19:01, Stefan Matheis <[hidden email]> wrote:

> On September 29, 2016 at 12:05:12 PM, Dawid Weiss ([hidden email]) wrote:
>> > As a project I feel it is unnecessary to have 2933 unresolved issues in JIRA.
>>
>> Some of these are old ideas, but remain valid (and are still
>> unresolved), Jan. This has been discussed in the past without clear
>> resolution.
>>
>
> Which is absolutely fine - at least how i understand Jan’s suggestion. The point would probably be to revisit those from time to time and decide if they are still valid or perhaps already done as part of another ticket or something along the lines.
>
>
> On September 29, 2016 at 11:53:37 AM, Jan Høydahl ([hidden email]) wrote:
>> Furthermore the time to first response is not uncommonly 90 days or more!
>> I think we should strive to have no newly opened issues older than 7 days
>> without at least having one response, question, +1/-1 etc. Perhaps with
>> the exception of issues created by the committers or assigned to someone?
>
> I like it. I’m not even sure i’d make an expection for issues that are assigned to someone - especially new users tend to use JIRA in ways we probably are not aware of (including setting an estimate and stuff like that)
>
>
> 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?
>
> -Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Jan Høydahl / Cominvent
In reply to this post by Cassandra Targett
29. sep. 2016 kl. 19.35 skrev Cassandra Targett <[hidden email]>:
...
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.

My 7-day comment was not a proposal to auto-close, but as some kind
of internal goal of the community.

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.

Yes! A bigger ambition is to write a Python script that monitors and
enforces our agreed-upon rules and thresholds. If INFRA will give us
a user with API access for our projects we have ability to script just about anything.

In addition to generating a weekly mail report, the lucene_jira.py script 
could also perform various actions proactively and automatically


The diagram suggests a custom automatic state transition by the script.
Issues older than 6m with no comments in 30d will receive a comment
“Issue seems to be inactive, will auto-close in 30d unless new activity.
If you want to close for now but be reminded in 12months, please close
manually with resolution=Later”.
The script will then tag the issue with a custom label “warn_close” which
it can use to decide whether to actually close after another 30d or not.
Likewise, we can monitor certain conditions such as new issues without
comments, issues with patch that may require committer attention etc.
Those issues being closed as “Later” will also be nagged every 12months
by the script, probably triggering either re-open or final close.

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.

We already have the “Later” resolution (6 issues in Solr, 14 in Lucene).

Jan
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
I think the first step should be about increasing visibility rather than enforcing transition rules (so the report and reminder part).

I've just been looking into Jira's reporting and it is quite flexible, but takes a while to wrap a mind around. Somebody digging in and coming up with great Solr-specific dashboards might be a way forward. People who are interested could then add them to their own screens.

The next step would be to take those dashboards and run them centrally (e.g. on Amazon/Google AppEngine) with per-user information, to avoid those users needing to do the configuration.

The next (or alternative) step would be to export JIRA data and do information crunching that the built-in reporting currently does not do. Reports I am specifically thinking about:
*) Issues open for more than X days, in which the only activity (description+comments) comes from an original author. This would catch the issues nobody replied to yet
*) Issues opened by a non-committer (to let people see the external community contribution and do triage/first-response)
*) Issues where "I" made the last comment and X amount of time passed since - useful for "next action" reminders
*) Issues older than X days that have '*.patch' attachment file (as opposed to random attachment)

None of the above needs INFRA, as Jira will happily export up to ~200 issues with full details per API call. I am doing some real basic exploration about it right now.

I also mentioned before, but perhaps not in this discussion, that it would be really nice to have some clarity/improvements on tagging the issues. For example, I want to tag all Admin UI issues, but not sure what the right tag would be. I could of course come up with one myself, but the joke about having one-more standard worries me. I would be happier to work within some sort of consent-oriented taxonomy. Though, this could be just my problem, because I am choosing to do lower-hanging fruits over multiple components rather than dark magic in selected few.

> We already have the “Later” resolution (6 issues in Solr, 14 in Lucene).
I've just tried closing SOLR-373. I don't think it worked the way I thought it would work. It is now closed but still with the Resolution "later". UI did not give me an easy option to edit that as I close. I think "Later" may work better as the Status field (So, Opened, Reopened, Later, Closed), but I am not sure INFRA would want to change that.

Regards,
   Alex.


----
Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/

On 3 October 2016 at 03:23, Jan Høydahl <[hidden email]> wrote:
29. sep. 2016 kl. 19.35 skrev Cassandra Targett <[hidden email]>:
...
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.

My 7-day comment was not a proposal to auto-close, but as some kind
of internal goal of the community.

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.

Yes! A bigger ambition is to write a Python script that monitors and
enforces our agreed-upon rules and thresholds. If INFRA will give us
a user with API access for our projects we have ability to script just about anything.

In addition to generating a weekly mail report, the lucene_jira.py script 
could also perform various actions proactively and automatically


The diagram suggests a custom automatic state transition by the script.
Issues older than 6m with no comments in 30d will receive a comment
“Issue seems to be inactive, will auto-close in 30d unless new activity.
If you want to close for now but be reminded in 12months, please close
manually with resolution=Later”.
The script will then tag the issue with a custom label “warn_close” which
it can use to decide whether to actually close after another 30d or not.
Likewise, we can monitor certain conditions such as new issues without
comments, issues with patch that may require committer attention etc.
Those issues being closed as “Later” will also be nagged every 12months
by the script, probably triggering either re-open or final close.

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.

We already have the “Later” resolution (6 issues in Solr, 14 in Lucene).

Jan

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Susheel Kumar-3
I also agree with Alex regarding tagging the issues and perhaps if possible/known, tag the effort/complexity level (high, medium, easy or beginner/seasoned etc.) that new comers can also contribute. This may help to get the low-hanging fruits to get done quicker and close some of them.


Thanks,
Susheel

On Sun, Oct 2, 2016 at 9:38 PM, Alexandre Rafalovitch <[hidden email]> wrote:
I think the first step should be about increasing visibility rather than enforcing transition rules (so the report and reminder part).

I've just been looking into Jira's reporting and it is quite flexible, but takes a while to wrap a mind around. Somebody digging in and coming up with great Solr-specific dashboards might be a way forward. People who are interested could then add them to their own screens.

The next step would be to take those dashboards and run them centrally (e.g. on Amazon/Google AppEngine) with per-user information, to avoid those users needing to do the configuration.

The next (or alternative) step would be to export JIRA data and do information crunching that the built-in reporting currently does not do. Reports I am specifically thinking about:
*) Issues open for more than X days, in which the only activity (description+comments) comes from an original author. This would catch the issues nobody replied to yet
*) Issues opened by a non-committer (to let people see the external community contribution and do triage/first-response)
*) Issues where "I" made the last comment and X amount of time passed since - useful for "next action" reminders
*) Issues older than X days that have '*.patch' attachment file (as opposed to random attachment)

None of the above needs INFRA, as Jira will happily export up to ~200 issues with full details per API call. I am doing some real basic exploration about it right now.

I also mentioned before, but perhaps not in this discussion, that it would be really nice to have some clarity/improvements on tagging the issues. For example, I want to tag all Admin UI issues, but not sure what the right tag would be. I could of course come up with one myself, but the joke about having one-more standard worries me. I would be happier to work within some sort of consent-oriented taxonomy. Though, this could be just my problem, because I am choosing to do lower-hanging fruits over multiple components rather than dark magic in selected few.

> We already have the “Later” resolution (6 issues in Solr, 14 in Lucene).
I've just tried closing SOLR-373. I don't think it worked the way I thought it would work. It is now closed but still with the Resolution "later". UI did not give me an easy option to edit that as I close. I think "Later" may work better as the Status field (So, Opened, Reopened, Later, Closed), but I am not sure INFRA would want to change that.

Regards,
   Alex.


----
Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/

On 3 October 2016 at 03:23, Jan Høydahl <[hidden email]> wrote:
29. sep. 2016 kl. 19.35 skrev Cassandra Targett <[hidden email]>:
...
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.

My 7-day comment was not a proposal to auto-close, but as some kind
of internal goal of the community.

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.

Yes! A bigger ambition is to write a Python script that monitors and
enforces our agreed-upon rules and thresholds. If INFRA will give us
a user with API access for our projects we have ability to script just about anything.

In addition to generating a weekly mail report, the lucene_jira.py script 
could also perform various actions proactively and automatically


The diagram suggests a custom automatic state transition by the script.
Issues older than 6m with no comments in 30d will receive a comment
“Issue seems to be inactive, will auto-close in 30d unless new activity.
If you want to close for now but be reminded in 12months, please close
manually with resolution=Later”.
The script will then tag the issue with a custom label “warn_close” which
it can use to decide whether to actually close after another 30d or not.
Likewise, we can monitor certain conditions such as new issues without
comments, issues with patch that may require committer attention etc.
Those issues being closed as “Later” will also be nagged every 12months
by the script, probably triggering either re-open or final close.

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.

We already have the “Later” resolution (6 issues in Solr, 14 in Lucene).

Jan


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Adrien Grand
In reply to this post by Alexandre Rafalovitch
Le lun. 3 oct. 2016 à 03:38, Alexandre Rafalovitch <[hidden email]> a écrit :
I think the first step should be about increasing visibility rather than enforcing transition rules (so the report and reminder part).

+1 I like the idea of a weekly report to make it less likely for issues to be unnoticed, but the enforcement of transition rules feels too rigid to me.

lucene_jira_states.png (56K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Jeff Wartes
In reply to this post by Erick Erickson
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" <[hidden email]> 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
    <[hidden email]> wrote:
    > On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
    > For additional commands, e-mail: [hidden email]
    >
   
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Jan Høydahl / Cominvent
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 <[hidden email]>:

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" <[hidden email]> 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
   <[hidden email]> wrote:
On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


   ---------------------------------------------------------------------
   To unsubscribe, e-mail: [hidden email]
   For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
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 <[hidden email]> 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 <[hidden email]>:
>
> 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" <[hidden email]> 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
>    <[hidden email]> wrote:
>
> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>    ---------------------------------------------------------------------
>    To unsubscribe, e-mail: [hidden email]
>    For additional commands, e-mail: [hidden email]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Cassandra Targett
In terms of a report, I found a template that uses JIRA's API to
import issues to a Google Sheet:
http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet

I made some modifications to the original and have shared it for
public viewing:
https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0

I was able to pull in issues with my JIRA login without asking INFRA,
so I think committers at least already have permissions to use the
JIRA API.

The template Sheet was initially created to make a board with cards
for planning, but I have removed those tabs and the script that
generates the cards. So ignore anything about "story cards" that you
might see in instructions or anywhere else.

There are a few issues with the API output that makes the data a
little difficult to work with. Most of the fields I wanted include a
bunch of metadata JIRA uses for display. And the date field won't
convert from a timestamp to a date. The date issue is the worst of
these, for aging purposes, but there might be something we can do in
the script  that pulls the data to fix this.

Despite that, it's still possible to make a simple report from this.
I've added a tab "Stats" that shows some initial (easy) calculations -
# of Issues by Type, # older than 2016 by types, # unassigned, a
breakdown by year.

Google's flavor of javascript (Google Apps Script) runs the sheet, so
I think we could add to the main script, or add other scripts, if we
want to. I know pretty close to zero javascript, however, so would
need help there.

JIRA can do a lot of this same stuff in its own dashboards (especially
basic stuff), but that's very much opt-in by individual users. It
sounds like some folks would prefer something pushed to the community.
We could do a combination, however - I could take a stab at a shared
dashboard people could opt into, and also send out a summary weekly
based on a report generated somehow.

I have no ego invested in the import-to-spreadsheet example I'm
sharing here; if it won't work for helping us to stay on top of aging
issues, I can toss it. It was just an option to explore since there is
an easy-to-use template already out in the world. If we do think it
will work, though, I can give edit permissions to the folks who want
to help get it into shape.

On Wed, Oct 5, 2016 at 11:24 AM, Alexandre Rafalovitch
<[hidden email]> wrote:

> 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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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" <[hidden email]> 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
>>    <[hidden email]> wrote:
>>
>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>    ---------------------------------------------------------------------
>>    To unsubscribe, e-mail: [hidden email]
>>    For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
 I believe the first 3 dashboards can be done in JIRA itself. I have
something similar, but unfortunately cannot share the dashboard (no
permission it seems).

The last one (breakdown of creation date? by year) is something that
JIRA does not seem to be able to give.

In terms of pulling data, I was able to build an API to pull up to 200
issues from JIRA at a time with full case information in the - as
Cassandra discovered - rather convoluted XML. So, it would not be too
hard to run several APIs and merge the results to get full export. And
then maybe run daily/weekly export and merge/override. Then, it is
pre-process and distribute.

It is totally doable. We just need to firm up the business
requirements. What kind of reports people feel would be useful for
_them_ to be more proactive. I've listed my ideas earlier, but not
sure if they would be useful to others.

Regards,
   Alex.
P.s. Do we need a JIRA for this?
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 6 October 2016 at 00:06, Cassandra Targett <[hidden email]> wrote:

> In terms of a report, I found a template that uses JIRA's API to
> import issues to a Google Sheet:
> http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet
>
> I made some modifications to the original and have shared it for
> public viewing:
> https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0
>
> I was able to pull in issues with my JIRA login without asking INFRA,
> so I think committers at least already have permissions to use the
> JIRA API.
>
> The template Sheet was initially created to make a board with cards
> for planning, but I have removed those tabs and the script that
> generates the cards. So ignore anything about "story cards" that you
> might see in instructions or anywhere else.
>
> There are a few issues with the API output that makes the data a
> little difficult to work with. Most of the fields I wanted include a
> bunch of metadata JIRA uses for display. And the date field won't
> convert from a timestamp to a date. The date issue is the worst of
> these, for aging purposes, but there might be something we can do in
> the script  that pulls the data to fix this.
>
> Despite that, it's still possible to make a simple report from this.
> I've added a tab "Stats" that shows some initial (easy) calculations -
> # of Issues by Type, # older than 2016 by types, # unassigned, a
> breakdown by year.
>
> Google's flavor of javascript (Google Apps Script) runs the sheet, so
> I think we could add to the main script, or add other scripts, if we
> want to. I know pretty close to zero javascript, however, so would
> need help there.
>
> JIRA can do a lot of this same stuff in its own dashboards (especially
> basic stuff), but that's very much opt-in by individual users. It
> sounds like some folks would prefer something pushed to the community.
> We could do a combination, however - I could take a stab at a shared
> dashboard people could opt into, and also send out a summary weekly
> based on a report generated somehow.
>
> I have no ego invested in the import-to-spreadsheet example I'm
> sharing here; if it won't work for helping us to stay on top of aging
> issues, I can toss it. It was just an option to explore since there is
> an easy-to-use template already out in the world. If we do think it
> will work, though, I can give edit permissions to the folks who want
> to help get it into shape.
>
> On Wed, Oct 5, 2016 at 11:24 AM, Alexandre Rafalovitch
> <[hidden email]> wrote:
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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" <[hidden email]> 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
>>>    <[hidden email]> wrote:
>>>
>>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>    ---------------------------------------------------------------------
>>>    To unsubscribe, e-mail: [hidden email]
>>>    For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Jeff Wartes
I was thinking about this some more last night, and since I’m in software, here’s the software I think I’d want:

Create a list of Alerts, each of which know how to do two things: 1) Determine whether a given jira issue matches the alert 2) Determine an Alertee for a matching issue.
One of Alexandre’s examples in this context: 1) If the issue hasn’t had an update in a week, and the last update was by a committer, it’s a match. 2) The committer with the last comment is the Alertee.
Another example: 1) If the issue has a patch file or a github pull request comment, but isn’t assigned to anyone, it’s a match. 2) This dev mailing list is the Alertee

Every week, iterate through all unresolved issues, and give every Alert definition the chance to gather the list of matching tickets.
Then:
1. Dump each Alert’s list of issues on a web page someplace. Include diffs vs the last run, so you can see if a given Alert’s list is growing over time.
2. Get the distinct list of Alertee for all issues that matched any Alerts, and send each Alertee one email with the list of issues mapped to that Alertee, grouped by Alert type.

So you give periodic reminders to exactly the people who should get them, and you also have a place you can see this week’s status for everything. For bonus points, people could squelch getting the email if it only contained issues derived from certain Alerts.


On 10/5/16, 10:42 AM, "Alexandre Rafalovitch" <[hidden email]> wrote:

     I believe the first 3 dashboards can be done in JIRA itself. I have
    something similar, but unfortunately cannot share the dashboard (no
    permission it seems).
   
    The last one (breakdown of creation date? by year) is something that
    JIRA does not seem to be able to give.
   
    In terms of pulling data, I was able to build an API to pull up to 200
    issues from JIRA at a time with full case information in the - as
    Cassandra discovered - rather convoluted XML. So, it would not be too
    hard to run several APIs and merge the results to get full export. And
    then maybe run daily/weekly export and merge/override. Then, it is
    pre-process and distribute.
   
    It is totally doable. We just need to firm up the business
    requirements. What kind of reports people feel would be useful for
    _them_ to be more proactive. I've listed my ideas earlier, but not
    sure if they would be useful to others.
   
    Regards,
       Alex.
    P.s. Do we need a JIRA for this?
    ----
    Newsletter and resources for Solr beginners and intermediates:
    http://www.solr-start.com/
   
   
    On 6 October 2016 at 00:06, Cassandra Targett <[hidden email]> wrote:
    > In terms of a report, I found a template that uses JIRA's API to
    > import issues to a Google Sheet:
    > http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet
    >
    > I made some modifications to the original and have shared it for
    > public viewing:
    > https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0
    >
    > I was able to pull in issues with my JIRA login without asking INFRA,
    > so I think committers at least already have permissions to use the
    > JIRA API.
    >
    > The template Sheet was initially created to make a board with cards
    > for planning, but I have removed those tabs and the script that
    > generates the cards. So ignore anything about "story cards" that you
    > might see in instructions or anywhere else.
    >
    > There are a few issues with the API output that makes the data a
    > little difficult to work with. Most of the fields I wanted include a
    > bunch of metadata JIRA uses for display. And the date field won't
    > convert from a timestamp to a date. The date issue is the worst of
    > these, for aging purposes, but there might be something we can do in
    > the script  that pulls the data to fix this.
    >
    > Despite that, it's still possible to make a simple report from this.
    > I've added a tab "Stats" that shows some initial (easy) calculations -
    > # of Issues by Type, # older than 2016 by types, # unassigned, a
    > breakdown by year.
    >
    > Google's flavor of javascript (Google Apps Script) runs the sheet, so
    > I think we could add to the main script, or add other scripts, if we
    > want to. I know pretty close to zero javascript, however, so would
    > need help there.
    >
    > JIRA can do a lot of this same stuff in its own dashboards (especially
    > basic stuff), but that's very much opt-in by individual users. It
    > sounds like some folks would prefer something pushed to the community.
    > We could do a combination, however - I could take a stab at a shared
    > dashboard people could opt into, and also send out a summary weekly
    > based on a report generated somehow.
    >
    > I have no ego invested in the import-to-spreadsheet example I'm
    > sharing here; if it won't work for helping us to stay on top of aging
    > issues, I can toss it. It was just an option to explore since there is
    > an easy-to-use template already out in the world. If we do think it
    > will work, though, I can give edit permissions to the folks who want
    > to help get it into shape.
    >
    > On Wed, Oct 5, 2016 at 11:24 AM, Alexandre Rafalovitch
    > <[hidden email]> wrote:
    >> 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 <[hidden email]> 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 <[hidden email]>:
    >>>
    >>> 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" <[hidden email]> 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
    >>>    <[hidden email]> wrote:
    >>>
    >>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
    >>> For additional commands, e-mail: [hidden email]
    >>>
    >>>
    >>>    ---------------------------------------------------------------------
    >>>    To unsubscribe, e-mail: [hidden email]
    >>>    For additional commands, e-mail: [hidden email]
    >>>
    >>>
    >>>
    >>>
    >>> ---------------------------------------------------------------------
    >>> To unsubscribe, e-mail: [hidden email]
    >>> For additional commands, e-mail: [hidden email]
    >>>
    >>>
    >>
    >> ---------------------------------------------------------------------
    >> To unsubscribe, e-mail: [hidden email]
    >> For additional commands, e-mail: [hidden email]
    >>
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail: [hidden email]
    > For additional commands, e-mail: [hidden email]
    >
   
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JIRA maintenance and response times

Alexandre Rafalovitch
Progress update,

I had pinged Mike McCandless and he - very kindly - implemented some
new facets for the Jirasearch that - I think - would help for this
discussion. The full list of changes is at
http://blog.mikemccandless.com/2016/10/jiraseseach-20-dog-food-using-lucene-to.html

The summary relevant right now is that we can now ALSO filter issues
by the last person who updated it as well as the time that passed
since that last update. And - that was his idea - who actually
committed within that issue. None of these were possible with Jira JQL
queries, however smart.

Which means I can run the queries such as:
http://jirasearch.mikemccandless.com/search.py?chg=dds&text=&a1=updatedOld&a2=%3E+1+week+ago&page=0&searcher=938&sort=recentlyUpdated&format=list&id=r3zft095hlwr&dd=project%3ASolr&dd=status%3AOpen%2CReopened&dd=lastContributor%3AAlexandre+Rafalovitch&newText=

(Opened/Reopened Solr issues in which the last comment was mine and
it's been longer than a week) - which means follow-up time.

Or
http://jirasearch.mikemccandless.com/search.py?chg=dds&text=&a1=hasCommits&a2=0&page=0&searcher=938&sort=recentlyUpdated&format=list&id=qkprrewu1d2r&dd=project%3ASolr&dd=status%3AOpen%2CReopened&dd=allUsers%3AAlexandre+Rafalovitch&dd=updatedOld%3A%3E+3+months+ago&newText=

(Discussions I participated in that has gone dark without outcome
(commit) for more than 3 months.)

I think that's a great step forward both for interactive exploration
as well as for this specific discussion on whether something like that
should be an automatic report for individuals. Because, as part of the
upgrade, Mike also open-sourced the tools to download JIRAs into a
form where we could run the tools, summary reports,visualizations,
etc.

Nothing is stopping us now but the consensus on what exactly the next
step should be (the hard part, I know).

Regards,
   Alex.
----
Solr Example reading group is starting November 2016, join us at
http://j.mp/SolrERG



On 5 October 2016 at 16:53, Jeff Wartes <[hidden email]> wrote:

> I was thinking about this some more last night, and since I’m in software, here’s the software I think I’d want:
>
> Create a list of Alerts, each of which know how to do two things: 1) Determine whether a given jira issue matches the alert 2) Determine an Alertee for a matching issue.
> One of Alexandre’s examples in this context: 1) If the issue hasn’t had an update in a week, and the last update was by a committer, it’s a match. 2) The committer with the last comment is the Alertee.
> Another example: 1) If the issue has a patch file or a github pull request comment, but isn’t assigned to anyone, it’s a match. 2) This dev mailing list is the Alertee
>
> Every week, iterate through all unresolved issues, and give every Alert definition the chance to gather the list of matching tickets.
> Then:
> 1. Dump each Alert’s list of issues on a web page someplace. Include diffs vs the last run, so you can see if a given Alert’s list is growing over time.
> 2. Get the distinct list of Alertee for all issues that matched any Alerts, and send each Alertee one email with the list of issues mapped to that Alertee, grouped by Alert type.
>
> So you give periodic reminders to exactly the people who should get them, and you also have a place you can see this week’s status for everything. For bonus points, people could squelch getting the email if it only contained issues derived from certain Alerts.
>
>
> On 10/5/16, 10:42 AM, "Alexandre Rafalovitch" <[hidden email]> wrote:
>
>      I believe the first 3 dashboards can be done in JIRA itself. I have
>     something similar, but unfortunately cannot share the dashboard (no
>     permission it seems).
>
>     The last one (breakdown of creation date? by year) is something that
>     JIRA does not seem to be able to give.
>
>     In terms of pulling data, I was able to build an API to pull up to 200
>     issues from JIRA at a time with full case information in the - as
>     Cassandra discovered - rather convoluted XML. So, it would not be too
>     hard to run several APIs and merge the results to get full export. And
>     then maybe run daily/weekly export and merge/override. Then, it is
>     pre-process and distribute.
>
>     It is totally doable. We just need to firm up the business
>     requirements. What kind of reports people feel would be useful for
>     _them_ to be more proactive. I've listed my ideas earlier, but not
>     sure if they would be useful to others.
>
>     Regards,
>        Alex.
>     P.s. Do we need a JIRA for this?
>     ----
>     Newsletter and resources for Solr beginners and intermediates:
>     http://www.solr-start.com/
>
>
>     On 6 October 2016 at 00:06, Cassandra Targett <[hidden email]> wrote:
>     > In terms of a report, I found a template that uses JIRA's API to
>     > import issues to a Google Sheet:
>     > http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet
>     >
>     > I made some modifications to the original and have shared it for
>     > public viewing:
>     > https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0
>     >
>     > I was able to pull in issues with my JIRA login without asking INFRA,
>     > so I think committers at least already have permissions to use the
>     > JIRA API.
>     >
>     > The template Sheet was initially created to make a board with cards
>     > for planning, but I have removed those tabs and the script that
>     > generates the cards. So ignore anything about "story cards" that you
>     > might see in instructions or anywhere else.
>     >
>     > There are a few issues with the API output that makes the data a
>     > little difficult to work with. Most of the fields I wanted include a
>     > bunch of metadata JIRA uses for display. And the date field won't
>     > convert from a timestamp to a date. The date issue is the worst of
>     > these, for aging purposes, but there might be something we can do in
>     > the script  that pulls the data to fix this.
>     >
>     > Despite that, it's still possible to make a simple report from this.
>     > I've added a tab "Stats" that shows some initial (easy) calculations -
>     > # of Issues by Type, # older than 2016 by types, # unassigned, a
>     > breakdown by year.
>     >
>     > Google's flavor of javascript (Google Apps Script) runs the sheet, so
>     > I think we could add to the main script, or add other scripts, if we
>     > want to. I know pretty close to zero javascript, however, so would
>     > need help there.
>     >
>     > JIRA can do a lot of this same stuff in its own dashboards (especially
>     > basic stuff), but that's very much opt-in by individual users. It
>     > sounds like some folks would prefer something pushed to the community.
>     > We could do a combination, however - I could take a stab at a shared
>     > dashboard people could opt into, and also send out a summary weekly
>     > based on a report generated somehow.
>     >
>     > I have no ego invested in the import-to-spreadsheet example I'm
>     > sharing here; if it won't work for helping us to stay on top of aging
>     > issues, I can toss it. It was just an option to explore since there is
>     > an easy-to-use template already out in the world. If we do think it
>     > will work, though, I can give edit permissions to the folks who want
>     > to help get it into shape.
>     >
>     > On Wed, Oct 5, 2016 at 11:24 AM, Alexandre Rafalovitch
>     > <[hidden email]> wrote:
>     >> 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 <[hidden email]> 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 <[hidden email]>:
>     >>>
>     >>> 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" <[hidden email]> 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
>     >>>    <[hidden email]> wrote:
>     >>>
>     >>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <[hidden email]> 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: [hidden email]
>     >>> For additional commands, e-mail: [hidden email]
>     >>>
>     >>>
>     >>>    ---------------------------------------------------------------------
>     >>>    To unsubscribe, e-mail: [hidden email]
>     >>>    For additional commands, e-mail: [hidden email]
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> ---------------------------------------------------------------------
>     >>> To unsubscribe, e-mail: [hidden email]
>     >>> For additional commands, e-mail: [hidden email]
>     >>>
>     >>>
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: [hidden email]
>     >> For additional commands, e-mail: [hidden email]
>     >>
>     >
>     > ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: [hidden email]
>     > For additional commands, e-mail: [hidden email]
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]