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" <arafa...@gmail.com> 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 <casstarg...@gmail.com> 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
> <arafa...@gmail.com> 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 <jan....@cominvent.com> 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 <jwar...@whitepages.com>:
>>>
>>> I’m not a committer, but Solr is the first major open source project
I’ve
>>> followed closely enough to get a feel for the actual community. The
issues
>>> coming up in this thread have been rattling around in my head for at
least
>>> the last year, and I’m absolutely thrilled to see this conversation. I
>>> nearly brought it up myself on couple of occasions, but I wasn’t sure
how
>>> much of this was common to all open source (volunteer-driven) projects.
>>>
>>> I’ve filed Solr issues, some with patches, some of which have been
accepted.
>>> Some went a different way than I expected, which is fine, but
unfortunately
>>> some also just rot, with the chances of them being useful going down
every
>>> day. I’d rather get a No.
>>>
>>> There have been a few cases where I’ve worked on a patch after
discussing
>>> and getting a favorable opinion from a committer, but even that doesn’t
seem
>>> to offer any assurance that the work will ever be reviewed.
>>>
>>> And frankly, yes, this effects how I deal with Solr issues. Among other
>>> things, it discourages me from contributing more work until I see
attention
>>> to the stuff I’ve already provided.
>>>
>>> Anything to help call out issues that need attention would be greatly
>>> appreciated, I think. I have a suspicion that the
Jira-notificaiton-firehose
>>> is the most common notification mechanism, and people generally just
look at
>>> whatever came out most recently there. Meaning, if something blew past
>>> unnoticed, it’s gone forever.
>>>
>>>
>>>
>>> On 9/29/16, 11:32 AM, "Erick Erickson" <erickerick...@gmail.com> wrote:
>>>
>>> Big +1 to this statement:
>>>
>>> ***********
>>> To me, the most urgent aspect of the problem is that Bugs are not
>>> getting verified and fixed as soon as possible, and non-committers
>>> (particularly) who take the time to create a patch for an improvement
>>> are not seeing their efforts acknowledged, let alone reviewed or
>>> committed
>>> ************
>>>
>>> This hits the nail on the head IMO. I wonder how many potential
>>> committers we've lost through inaction? Yonik's line about "you
>>> get to be a committer by acting like a committer" comes to mind.
>>> We have people "acting like committers" by submitting
>>> patches and the like then don't get back to them.
>>>
>>> Of course we all have our day jobs, limited time and at least
>>> some of us have these things called "lives".
>>>
>>> I'm not sure how to resolve the issue either. It can take
>>> significant time to even look at a patch and give any reasonable
>>> feedback....
>>>
>>> I'm glad for the conversation too, just wish I had a magic cure.
>>>
>>> Erick
>>>
>>>
>>> On Thu, Sep 29, 2016 at 10:35 AM, Cassandra Targett
>>> <casstarg...@gmail.com> wrote:
>>>
>>> On Thu, Sep 29, 2016 at 7:01 AM, Stefan Matheis <ste...@mathe.is> wrote:
>>>
>>> first idea about it: we could bring a script or something that collects
once
>>> a week information about all new issues and sends it to the dev-list?
so get
>>> a quick overview about what happend last week w/o too much trouble?
>>>
>>>
>>> +1 to this idea - awareness of the problem is the first step to being
>>> able to change it. And I agree it is a problem.
>>>
>>> It's enough of a problem that at Lucidworks we have added it to our
>>> priority list for the next year. Consequently, I've spent quite a bit
>>> of time looking at old issues in the past couple of months.
>>>
>>> To me, the most urgent aspect of the problem is that Bugs are not
>>> getting verified and fixed as soon as possible, and non-committers
>>> (particularly) who take the time to create a patch for an improvement
>>> are not seeing their efforts acknowledged, let alone reviewed or
>>> committed. I think this causes more bad impressions than someone's
>>> good idea for a new feature that doesn't get implemented. (BTW, Bugs
>>> alone make up 44% of all issues older than 6 months; Improvements are
>>> another 38% of old issues.)
>>>
>>> I fear a 7-day respond-or-close policy would frustrate people more.
>>> Users would see their issues now closed instead of just ignored, and
>>> if it gets a +1 from someone to stay open, it can still sit for the
>>> next 5 years the same way as today. We need to take that idea a step
>>> further.
>>>
>>> What would I suggest instead? Not sure. One very small suggestion is
>>> to add to Stefan's idea and send out a weekly mail about age of issues
>>> - # of issues over 6 months, % increase/decrease, # of bugs with no
>>> action in X days, # of improvements with patches that have no action
>>> in X days.
>>>
>>> Another idea is to have some kind of "parked" state in JIRA - like,
>>> not Closed but not Open either. I'm not convinced that won't add to
>>> the noise, but it might at least give us a better sense for ideas we
>>> just haven't gotten to and issues we haven't really looked at yet.
>>>
>>> Thanks for bringing this up, Jan. It's a necessary conversation to have.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
