|
|
|
I'm a geek (or at least like to think I am) and I have problems with Jira as well. When people like me (scripters) want to report a problem, we have to wade through stuff that is confusing to us, also. I know that the Lindens are aware of this issue because the geek-version of this issue, jira
Correction: WEB 153 is the number one jira issue, by votes, and the third highest WEB issue, by votes. Either way, the LIndens ARE aware of the issue. The upgrade no-doubt is meant to make it easier to get around, but I don't think its going to be nearly enough.
The equivalent complaint by the geeks.
That issue doesn't seem really equivalent. It only talks about a certain problem (confusing categorization), not the whole bug-reporting process in general.
I'm a casual person and appreciate such suggestions. I also value prior precedent, if you guys can point me to actual examples currently in use by other companies of really streamined bug reporting. PLEASE. Reason why – there doesn't appear to be a lot of precedent out there, and it helps to have inspiration to work from.
@Montana: re: language support, see my "change JIRA language tip" in: » http://blog.secondlife.com/2007/07/05/how-to-report-bugs-better/ Let me ask Rob Linden about some of these suggestions too. Also, Celierra or anyone who's comfortable: if you want to improve the actual Issue Tracker instructions: » https://wiki.secondlife.com/wiki/Issue_tracker since they're on the wiki, they're Resident-editable. Obviously, please don't excise anything essential, but feel free to clarify things which could be less cryptic. Also research if some of the above is possible with built-in JIRA; some of the more obvious things-we-wanna-do like "Sort bugs by resolved date" are not, and require plugins. I checked with Rob about this and small safe changes should be easy to do. I'll work with him to make tweaks and assure it won't break our import/sync process – it's likely we'll do related ones in concentrated batches.
Just wanted to update that some of the suggestions here, like wording changes, are really easily actionable – some isn't possible due to the limits of JIRA. To learn more about what's possible, see info on stuff like Dashboard portlets @ http://www.atlassian.com/software/jira/docs/latest/portlets_summary.html
Wish we could clearer break things into a checklist of sub-tasks here (as I'm used to doing in our internal Linden Lab JIRA) because some of the changes are greater in complexity and require plugins:, e.g., » http://confluence.atlassian.com/display/JIRAEXT/Filter+List+Plugin I can modify the default Dashboard layout too – I hope to have a closer look at that when I have some spare cycles. Oh, and I removed the "Clone" option. (OOH, we can use sub-tasks on the Issue Tracker! Try and divide this into smaller chunks if you'd like, Celierra.)
Thank you Torley! hugs
Still thinking about how to divide this up... Split it into five tasks.
I think that the "Linden Lab Issue ID" field should be made only accessible by Lindens, if possible. People constantly get confused and fill in an RT#, or their operating system, or an entire issue description in this box.
I've moved ...that said, once emailing works, I'm sure I'll get a huge deluge of emails from all the issues I've commented. Heh. I think it might also be a good idea to make it more clear what priority people should give to each task. In the entire time this JIRA's been up, I've only seen two or three tasks that really truly deserved the BLOCKER priority. Blocker is only supposed to be used when the issue is so critical that all of SL grinds to a halt and that all LL development should grind to a halt while it's fixed. People often seem to declare an issue as a Blocker if SL grinds to a halt for THEM, ie for inability to log in or an obscure issue that they run into every day.
There's a nice handy description of what the priority levels are for if you click the ? button beside the priority dropdown, but most people don't read it. It might help to include it right with the priority dropdown on the create issue page, if possible. It would also help to clarify the priority level descriptions, such as "Major: major loss of function." If possible, it might be a good idea to limit setting the Blocker priority to the good-citizens or lindens groups. @Celierra: Awesome! Thanx, that'll help us focus better.
@Lex: Re: "Linden Lab Issue ID", great idea. Not sure how to limit JIRA fields to specific groups offhand, but I'll check with Rob. Very good point. Followup is crucial too, makes for more lively discussion and participation. I agree about clarifying priorities too... I have pretty much the same feelings about "Blocker", it's like, "It blocks ME!" Likewise, there are times when we have people mark crashes as "Critical" but noone else can repro/corroborate the info; those tend to be classed down to "Major" because their occurrence is rare. We need to keep emphasizing that part of our criteria for severity is # of Residents affected. I'll also ping Iridium about this, she wrote a great Issue Tracker how-to @ http://secondlife.com/newsletter/2007_07/tips.html I've added my request for a couple of large filters. Because, I think it's easy to lose track of things for me, and I'm a fairly technical user.
Just to clarify for those who are technical users of JIRA but not Concierge Account holders, outside North America, there is no such thing as an urgent response to support (unless you have a system for cheap international phone calls in place). In a recent blog entry after I posted something about Concierge ticket response times, no-one challenged the consensus that a billing query generally takes about one month to be resolved, and about two weeks to open. So the wiki or JIRA should not give out incorrect advice that urgent matters can be dealt with by support. I have no idea what the non-Concierge waiting times are, but they are presumably much longer.
Mercia I should add in response to Torley's question about other orgnisations' that as a long-time user of Open Source reporting systems, JIRA is simple to understand in comparison to something like Bugzilla (used by Mozilla among others) or Debian BTS. The only simpler things I have seen are just forums that the developers respond to, but that is inappropriately simple for something with as large a user-base as Second Life.
Although a website for reporting log-in failures (e.g., as an extension to all resident use of Region Down, which does have urgent response times to tickets), would help to cull the number of JIRA tickets that are Opened due to temporary grid problems and then clog up the database as Closed. Mercia Change the behaviour of the quick search. Have it automatically sort issues by creation date (descending), then by votes(descending).
This will allow new users to quickly find relevant issues. ie, if they're having login problems, the login issue that someone else already made earlier that day will appear at the top of the list, and they can just click into it and vote. That would drastically reduce the number of duplicates, I think. @WarKirby: I've wanted such a feature for awhile, but according to Atlassian, sorting columns persistently in the default navigator view (as accessed through Quick Search) isn't possible. Arg!
In lieu of that, the WindLight open bug list (as an example) – http://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=10970 Yeah, I wandered in, to add a feature to the LSL Wishlist, and have no idea where to go. I think it properly belongs in the LSL project, that should be suggested in the DOCumentation Project, which doesn't exist either.
Perhaps I could look up something in the KB, about looking things up in the Wiki, if I knew where to find the Index File. Let's make the Project Listings something the Users can understand. We wouldn't even have to call them Projects, if we don't care to explain what the term means. "If we had an index file, we could look up the index file there." |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Major
Streamline and clarify JIRA reporting process for non-technical users
Reopened
, common caveats, etc. If necessary, to utilize the whole screen width, one can leave the right column of the dashboard blank.
Oh, and since from Key Metrics, 60% of users don't have English as a first language, some language support would be good...
Maybe you could instigate a search on new reports, to throw up similar ones and ask is this your problem to cut down on the huge amount of duplicates, often there because the search has not used the same words. Fuzzy logic.
Plain simple search box on the front page that searches all, rather than trying to wok out if what you think is service is really miscellaneous or viewer. If a user is frustrated, it's because something doesn't work.
So all problem descriptions need to be less geeky.
You should use more standard stuff like Known bug, Workaround, Not yet fixed, feature request etc, and maybe have a scrolling window with new known and work around issues, so that is there is such a workaround people can find it quickly, or double click and vote easily.
It would have been nice to have had some consistency between reporting here and the inworld bug reports, the categories are totally different.
Think about having a geek subject flag, so minor geeky stuff that most people don't understand don't get included unless via checkbox. To a non geek with a problem, everything is critical and high priority lol
You basically need a very simple front end, and a complex one for those that know what they are doing. Use prefs or cookies to set up. If you read the blog, you get huge amounts of comments about how difficult JIRA is to use. I've not seen one person say how awesome it is. For most users, they certainly don't have ambient joy
Oh, and since from Key Metrics, 60% of users don't have English as a first language, some language support would be good...
Maybe you could instigate a search on new reports, to throw up similar ones and ask is this your problem to cut down on the huge amount of duplicates, often there because the search has not used the same words. Fuzzy logic.