Issue Tracker Forum Transcript

From Second Life Wiki
Revision as of 09:55, 19 December 2007 by Glenn Linden (talk | contribs) (New page: Issue Tracker SLDev Forum, Tuesday 27 Nov. 2007 ==Presenters today== * Rob Linden - Rob manages the Open Source initiative and public instance of Jira. * Aric Linden - Aric manages QA and...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Issue Tracker SLDev Forum, Tuesday 27 Nov. 2007

Presenters today

  • Rob Linden - Rob manages the Open Source initiative and public instance of Jira.
  • Aric Linden - Aric manages QA and is lead on bug triage

Overview of Issue Trackers

Rob: Issue Trackers are tools that designed to track ownership, state, priority, and enable discussion of issues. They let you see who an issue is assigned to, who is working on it (or who isn't), what it's state is (unassigned, worked on, being fixed, in codebase, released) and how important it is (priority). Jira provides all this and many more functions. A good system does those 4 things in a reasonable way.

LL has 2 Jira instances; one internally for LL employees, and a public one visible to Residents and Linden Lab employees.

Overview of the process

  1. Issue is read, and reviewed for completeness (may be sent back for more info or clarification)
  2. Bug Triage - review (Arics & Bridie hold separate bug triage) Mon and Wed, liseted on Linden public calendar
    • In those discussions, review what should happen with resident input
  3. Result: selected issues are imported to internal Jira and get integrated into internal process
  • Aric : Issue Tracker is a way to neutralize the communication process - remove personal opinions about importance.
  • Can see running dialog between different players and watch for priority by reading through comments on many postings
  • On public Jira, have several levels of magnitude for priority - Critical (doesn't work) to Minor (needs attention at some point).
  • Status reports our decision - never fixed, etc.
    • Being Worked on , Fixed Internally (will make its way out).
    • Internally track both tasks and projects, use to track work internally
  • Triages work the same way internally as externally; a weekly and monthly
  • Bridie's triage mostly RC and FirstLook issues

Public Jira Issue Lifecycle

  • Bug talked about at triage is imported from public to internal Jira
  • Assigned- most frequently to Aric to manage internal flow; occasionally to a specific person to massage or fix; most likely assigned to internal triage (Don, Bridie, Steve and Aric (Don & Steve are Studio directors), and assigned to a Studio
  • If Fixed, added to code base for release though the release cycle to Open Source drop and SL itself
  • Some aren't important enough to be taken immediately; those put in large pool and reviewed in monthly triage to be assigned
  • Public jira is updated with internal status, possibly assignment (WorkingOnIt Linden - assigned to internal developer); when fixed, status changed to Fixed Internally
  • Here's a typical agenda and resolution. Bug Triage home page with link to upcoming agendas

Searching for Issues

  • Kim Anubis: I have trouble searching for Issues.
  • Rob: Jira's search capability is a little tough to use. A trick to search it is to use Google to do a site search of Jira.com, rather than to use Jira's keyword search. (To do this, add site:jira.secondlife.com in your Google Search box, then the terms you're looking for.)

It's more important to file than to worry too much about duplicates - just don't be offended if we close it as a duplicate.

Status codes and actions

  • Resolved fixed: we've fixed it (we think) and hope that the reporter will confirm that it indeed has been fixed.
  • Cannot reproduce: we can't make the problem occur so we can fix it - the reporter should add more information, or seek independent verification of the problem
  • Resolved-duplicate: already been reported
  • Resolved-won't fix: not likely to get around to solving - either there's some other way of resolving it, or a known limitation we can't overcome

Jira Notification

  • Yes, we use them internally.
  • You can establish a watch.
  • There's a bug in public Jira that causes your email address to not get associated with your filed issue; we manually resync monthly, and are working to get that resolved.
  • The other way is a mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/jira-notify which notifies of all changes to Jira - it's very high volume, so you'll need to filter it.
  • When you create an issue, can you receive an email when someone comments?
  • Rob: If your email is in the system, when you report an issue, you're automatically set up as a watcher so that if anyone comments on that issue you'll be sent an email.
  • Using SL logins is causing some problems with email synchronization, but otherwise, it's a standard Jira implementation.

Can I connect inworld assets/scripts/content to an issue?

  • Aric Linden: yes you can. You can attach assets, scripts or images to a Jira issue; or take a screen shot or can point to specific inventory item by SLURL or other way.
  • As a reminder, I assume everyone here has written a bug. Anything you can do to help the developer replicate it is important - think of it as writing a recipe, step by step to get to result you don't want (bug), along with what you expected. Attachments (images, etc.) really help.

Blocks to using Jira

  • Rob: what is stopping you from using Jira as a tool, or has this session made you more likely to file a bug?
  • Marcoh Larsen: I find Jira complex.
  • Damanios Thetan: in the past, it was the performance, jira was kind of slow
  • Aric: Have you used other bug tracking
  • Marcoh: Topdesk and And another Dutch product CCA. And the one on the knownledge base ;-)
  • Rob: We're doing a couple of things to help on performance,including a tweak last Wednesday (it's been better)
  • Marcoh Larsen: Is there a tutorial or something like that?
  • Aric: When in doubt, take your best shot and move to the next field. I'd rather see an issue and have to figure out what's going on, than not have it reported. It's important for us to understand waht users see because we can't create every circumstance in our test environment.
  • If there's an issue that you need support for and it's stopping your business, use the standard support channels. Issue Tracker's not a time-sensitive tool. You can also help out support by also entering your problem in Issue Tracker (and reference it while talking to support); you'll get best of both worlds.
  • Aric: We strongly suggest you attend at least one triage to get a better sense of how things work. Most lindens are pretty willing to discuss things if you have questions. Also a good way to understand how SL works, and its issues and problems. It's a good way to bootstrap a very good understanding of Second Life.

Balancing Support and Jira

  • Marcoh Larsen: How do you (Linden Lab) combine your time between the standard support chanel and jira?
  • Rob: That's handled by two separate groups. The support channel is handled by a conventional support group that deals with issues that come through support channels. There's usually not a lot of overlap there. Generally when someone comes across something that's a bug that comes through the support channel, Support will file it in our internal Jira (since at that point it may have account information associated with it).
  • Aric: the other group that looks at things are the several of us (Aric and some other members of QA, Torley, who's phenomenal at looking through PJira to locate issues and problems, and some others) who look at issues and make sure things are getting caught. Then there are public triages -residents look through and generate lists of issues for Triage, and create agendas. I spend about 35% of my time in Issue Tracker; but there are other ways in which Issue Tracker items come to my attention, but I have to spend more time combing through the internal Jira.

What's one thing to remember?

  • Aric: detail, make it as much a recipe as you can so it can be reproduced internally and we can fix it.
  • Rob: It's there, it can be a very effective tool for ocmmunicating with the develeopment team here at Linden Lab.