The JIRA problem

The JIRA isn't working all that well as a public issue tracker.

There seems to be a few hundred regular JIRA users and an unknown number of users who have an issue, manage to login to JIRA and report something that's bothering them. Between these two groups of users they have managed to create currently over 2,700 open issues (not counting the resolved / closed issues).
It would be at *least* one persons full time job to sort through those issues and remove the duplicates, let alone flag up the important and / or easy fix problems to the developers.

With over 2,000 entries, it's not actually fair to blame people for opening duplicate issues, sometimes it's just not possible to easily find the matching issue that got phrased differently. But that duplicated issue is often a wasted vote on the real main issue. A casual user will log in, make the duplicate entry and get back out of the JIRA. They won't (generally) then come back if the issue gets closed and try and find the duplicate and vote on it. So we don't have an accurate picture generated of what the most commonly experienced problems are.

Because there are so few regular JIRA users, the most voted for entries have over 100 votes and the vast majority of issues have less than 3 votes. So the method of using votes to identify important issues works for maybe the top 50 issues at most, leaving the other thousands as unknown importance simply because no one has found them and voted on them.

Many issues discussed in these forums either should be, or are already entered in the JIRA, so a large amount of time is wasted discussing problems in Forums rather than voting for the relevant issues in the JIRA or opening a new item.

Having the developers work in an environment with 2,700 entries on the "to do" list must be frustrating and discouraging for them. In fact the human response would be to begin to ignore the JIRA as a source of things to do. It's also a huge waste of developers time if they do actually make a serious attempt to plough through the JIRA. I'm sure they could easily spend a day doing that, rather than actually dealing with the problems at hand (if they could figure out what they are).

In short. As it is. I just don't think it's working.

Hmm. Just realised this is "Feature Suggestions"... Trouble is. I don't see an easy answer. There are already JIRA entries for simplifying the JIRA so that new users can get around it more easily. I've a feeling that adding sub categories might help sift through the data "VWR - Crashes", "VWR - Audio", "VWR - Voice" and that kind of thing. At least it might help knock searching through those thousands of entries in to more manageable chunks. I don't think abandoning the JIRA is an option now, and the previous vote for feature system has been dismantled.
Maybe the answer is just for LL to assign one person to continually sift through all the entries and make all the "is linked to", "is duplicated by" notes. But that still doesn't solve the problem that not enough people are finding the issues relevant to them and voting on them.
As it is though it's a source of frustration for both users and developers. Somehow it needs to be managed better...

This is pretty much what happened to the old system too, they need a group of techsavy people who can takes submissions and screen them to get rid of the showstoppers like "my prim goldfish are too slow", "my letterbox won't rez"

LL has its own - private - JIRA the devs actually use to refer to bugs, they don't deal with P-JIRA at all except to import issues into the internal one (you can go to Bridie's office hour to see how that works).

As far as votes go, they're not terribly important. The order of things on JIRA is probably something along the lines of (random guess for the last two):

* reported bugs with an attached patch
* feature changes with an attached patch
* reported, reproducable bugs
* feature changes
* reported bugs that aren't reproducable

If your problem is a bug that isn't reproducable (ie random inventory loss) or a "meta issue" you can get 100 votes for it, it'll be behind a new feature with 0 votes that has a submitted patch for it.

You also have to account for the fact that Lindens live in a distant future while residents live in the present. If you come across a bug that happens to be part of something that will get changed a year down the line anyway, it's not a bug anymore since they'll get around to revamping that whole thing... some day.

I'm aware of the fact that issues from the JIRA get imported to an internal system, but it's crucial to get that initial point of contact working better than it is. However things get prioritised from it, it's still the official point of contact between SL users and the developers. While it's in the tangle it is, it's of little use to either except as a testament to a lot of bug reporting and feature requests going on.

In the spirit of adding yet another open issue to the JIRA ... http://jira.secondlife.com/browse/WEB-401
(And yes, I checked through over 250 entries looking for a duplicate).

Best solution would be to have a box that pops up with "Possible existing issues" as a user enters a title for their JIRA issue. This lets them see "Oh, my issue has already been reported" and hopefully cut down on the duplicates.
After that it is up to the JIRA users to self-police duplicates and other false reports, it's like a wiki for bug and feature tracking.

I do agree that it's annoying that many issues sit around with only a handful of votes, I often have to link to some of the more important ones just to get any attention to them.

I have never seen a public customer-issue tracking system that did not evince the same symptoms. LL's issue tracking is actually noteworthy in that there is actually a fairly high degree of participation from LL customer service and even, on occasion, from engineering.

Vote for http://jira.secondlife.com/browse/WEB-224 !!!

At this rate I'll never be able to get my fish in the mail.