Bug Tracker
The JIRA Issue Tracker is not for technical support-type requests. If you're looking for account-specific help, please use our support resources.
The issue tracker, known as "Public JIRA", "PJIRA", or just "JIRA", is an issue-tracking project management tool made by Atlassian and is used by the Second Life open source initiative. It is located at https://jira.secondlife.com and organizes issues (i.e. bugs and feature requests) submitted by the Second Life community into a searchable database. You, too, can submit issues you find when using the open source or standard versions of Second Life. Please familiarize yourself with the information in this page before proceeding to JIRA.
NOTE: All submissions to this site (JIRA included) are governed by the Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you've read, understood, and agreed to those terms.
How it works
Bug reports created in JIRA are composed of a description of the problem and, if possible, a reproduction. New features are composed of descriptions of the proposed feature and how it should work. Both types of issues then get contributions from other users, such as better or simpler descriptions and reproductions, and popular issues accumulate votes from other users. Programmers in the open source community can attach "patches", changes to the code that fix or implement the issue. These votes, as well as events like bug triages, help prioritize the issues. Those which are acknowledged are "imported" into the Lindens' private copy of JIRA.
After the issue gets Linden attention, others can still continue to help. Once the changes are completed and awaiting release to the public, the bug is marked as "resolved - fixed internally". When the change has been made available, it is marked "resolved - fixed", and when confirmed to the satisfaction of most users, "closed - fixed".
In addition to "fixed internally" and "fixed", an issue can also be resolved or closed if it appears to be a duplicate of another issue, unreproducible, misfiled, not a bug, incomplete, etc.
Second Life JIRA FAQ
Caveats
The JIRA Issue Tracker is not for technical support, so please do not enter issues like:
- "I can't login! Help me!"
- "I keep crashing and want it to stop now!"
- "Someone stole my L$"
- "The sim I'm in is LAGGIN BAD"
- "How do I build a house?"
- More examples of misfiled issues
Entering misfiled issues which aren't actionable and don't contain clear instructions (see below for more info) makes it harder for your fellow Residents to use the Issue Tracker. If you're looking for personal assistance, please send your message to the right place by contacting Support (towards the bottom of the page), and be sure to include useful details to help us help you.
Before reporting issues, we recommend you thoroughly search the support resources first and look for the latest news and status reports on the Official Linden Blog.
Bugs & New Features
- Please read QA Bug Submission Guidelines before submitting a a bug.
- You can also propose new features through JIRA. (JIRA is emerging to succeed the Feature Voting Tool with your help, because it has better search and parallels the way we Lindens internally organize issues. Plus, you can discuss with other Residents.)
User profile
- Each JIRA user has a profile. The profile consists of your Username (SL name), Fullname (in our case, also your SL name), and all of the JIRA groups you belong to. For most people, this means "jira-users."
- The email address associated with your account shall remain anonymous to other users. The address is not visible or configurable at this time. Direct import of your email address from Second Life's database is currently disabled.
- The JIRA profile is not editable because allowing changes would introduce conflicts with your Second Life account. If you wish to edit account information such as your email address, please login to the account management page at secondlife.com.
Projects and Components
- Projects are used to categorize issues into logical groups.
- Components are used to specify which part of a system the issue affects. In other words, what is the scope of the problem within a project.
| Viewer (VWR) | Service (SVC) | Website (WEB) | Miscellaneous (MISC) |
|---|---|---|---|
|
|
|
|
Second Life Viewer (VWR)
Issues pertaining to the Second Life viewer are reported under this project.
Examples:
- llGetDate() is returning the wrong date Observed at 10:30 PM PDT on March 19, llGetDate() returns 2007-03-20 (Component = Scripting)
- "My avatar clothing is all black after installing a video driver update" (Component = Avatar/Character)
- "Objects in my Inventory do not remain sorted in the correct order after logging out and back in again" (Component = Inventory)
- For about 2 weeks "Recent Items" in my Inventory is not "recent Items" anymore. All the folders are open and everything in my inventory is seen. So it is impossible to see which items are recent.
Second Life Service (SVC)
Issues pertaining to the Second Life service are reported here.
Examples:
- "Server performance decreases when several avatars teleport into the region at once" (Component = Performance and/or Teleport)
- "My scripted objects are not able to talk to the outside world after Second Life grid downtime" (Component = Scripts).
Second Life Website (WEB)
Issues pertaining to the Second Life website are in this project.
Examples:
- "Wiki prevents login for users with a dash in their name" (Component = wiki.secondlife.com)
- "jira.secondlife.com always forces me to authenticate even if I save my login information" (Component = jira.secondlife.com).
Second Life Miscellaneous (MISC)
Any other type of issue should be reported in the MISC project.
Example:
- "The TOS does not allow me to edit the viewer source code" (Component = Miscellaneous)
Security Issues -- a.k.a "the missing Fifth Project"
Issues pertaining to the security of Second Life should be emailed to the Second Life Security mailing list rather than posted on jira.secondlife.com. Emailing them directly to Linden Lab helps us keep Second Life secure!
See security issues page for more information about submitting issues and collecting bounties for responsibly reporting valid security issues.
Searching
Parameters
- JIRA searching is easy once you know a bit about the parameters you may use.
- For instructions on searching in JIRA, please visit JIRA query syntax and JIRA quick search.
Perform a search
- First, click on the "Find Issues" link at the top of the screen.
- Next, enter the parameters you wish to search for in the search pane on the left-hand side of the screen.
- As an example, if I wish to search for issues that have not been resolved containing the word "avatar", I would choose the following parameters:
- Project = all projects
- Text search = avatar
- Resolutions = Unresolved
- Another sample search would be for any issues that are fixed in the last week in a particular project. For example, I want to find all bugs in the Second Life Viewer project that were resolved between February 1, 2007 and February 14, 2007. I would enter the following parameters:
- (Optional: Click the "New" link in the search pane to clear settings from any previous searches)
- Project = Second Life Viewer
- Resolution = Fixed
- Updated After = January 31, 2007
- Updated Before = February 15, 2007
Saving a search as a Filter
- A search filter is a saved search that you may share with others.
- After performing a search as described above, you may save it as a filter by clicking the "Save" link in the Search pane.
- Name the filter something meaningful, for example "Unresolved avatar bugs in all projects."
- Now you can access the search and run it at any time by clicking the "Filter" link in the top right-hand side of the page. This saves time and effort, especially if you frequently run the same complex search and want a handy shortcut!
Reporting an issue in JIRA
To report a new feature, bug or problem encountered while using Second Life Open Source Viewer or the Second Life Service itself, please log in to jira.secondlife.com.
Determine if the issue has already been submitted
Upon login to JIRA, you will land on the Home page. Here you have access to some global filters which give you access to the most up-to-date information on submitted issues. The preset filters include all unresolved (unfixed or untested) issues within each project. Of course you may create and save your own filters at any time, or simply run a new search. Either way, it is best practice to search for issues you wish to report in several ways before submitting them!
If the issue already was submitted, feel free to leave a comment containing supporting information, or if it's a bug, possibly another reproduction for the QA team. The more information we have about a specific issue, the higher chance of a resolution.
It can't be emphasized enough that searching for existing issues before filing a new one is the most important step in the submission process. Issues submitted more than once take time and effort to find and categorize -- and that is time our team could be spending testing issues and fixing problems instead. The same is true for new features already proposed by other Residents, because duplicates dilute votes, making them less effective.
Read the QA Bug Submission Guidelines
Before you submit a bug, be sure you are familiar with our QA Bug Submission Guidelines. Following them ensures our QA team's ability to reproduce the issue and transfer it to our internal tracking system for resolution by the Linden Lab Development Team!
Submitting a bug
To create a new bug in JIRA, do the following:
- Log in through the link in the upper-right corner (if you haven't already).
- Click the "Create New Issue" link in the blue navigation bar towards the top of the screen.
- Select a project that most closely describes the kind of bug you are submitting
- Select "Bug" as your "Issue Type".
- Enter a concise yet descriptive summary of the issue
- Be careful to omit Resident names or other personally-identifying information if it can be avoided!
- Select a component that narrows the scope of the bug
- Describe the environment in which the problem occurs
- For example, "Only happens with Mac OS X 10.4.1," or "Seen only with NVIDIA GeForce Go 7800 card," etc.
- Enter a detailed description of the issue:
- Steps to reproduce the bug (how to make the bug happen)
- Observed results (what happens when the bug occurs)
- Expected results (what behavior you would have expected instead)
- Again, be as detailed as possible without including personal information!
- Finally, click "Create" to create a new bug
Submitting a new feature
The process is similar to submitting a bug, with the following differences:
- You select "New Feature" instead of "Bug" as your "Issue Type".
- Instead of a "reproduction", clearly describe what the desired implementation and functionality of this new feature is. Make sure it hasn't already been done — you can refer to release notes for historical context and read our blog to learn more about what we're doing next.
For both bugs and new features, feel free to include links to other relevant info for an issue, such as forum and blog posts.
Voting for issues
You can vote for new features and bugs that you wish to see resolved, and view all issues by # of votes. JIRA uses approval voting, so you can vote for as many (or few) issues as you'd like, and you get 1 vote per issue.
Votes can readily be used as part of our prioritization process. Note that since we need to look at aspects such as feasibility and the time required for implementation, a highly-voted issue isn't necessarily going to be resolved ahead of a lesser-voted, but more doable one.
Return to check on issue status
Linden Lab will review issues submitted to jira.secondlife.com on a regular basis. The engineering team may require additional information from the issue reporter, or other contributors, so reviewing all of your created/commented issues regularly will be useful while email support in JIRA is disabled.
Also, when issues are resolved internally the external site will be updated as well, so check your issues for changes on a regular basis.
Issue States
Here is how Linden Lab is using the resolutions:
- Open - This is an issue that belongs to the Assignee to resolve. The assignee may fix the issue, or kick the issue back to the reporter by marking it "Resolved" (see below)
- In Progress - This is how a developer signals to everyone that he/she is working on the issue.
- Reopened - same as "Open".
- Resolved - This is an implicit assignment back to the reporter of the issue. It is not closed yet, but rather in a state of limbo that depends on the resolution. It's up to the Reporter to decide whether to reopen an issue, or close it.
- Fixed - means that the bug is fixed in a public release of Second Life.
- Fixed Internally - means that the bug is fixed in a version of the code that should soon be publicly available.
- Won't Fix - means that the assignee doesn't believe this issue should ever be fixed.
- Duplicate - means that there's some other issue that describes the same problem/idea.
- Needs More Info - this issue lacks information
- Cannot Reproduce - we're applying this label pretty liberally. Please provide a detailed description of how to reproduce a problem. Issues that can't be reproduced will eventually be closed.
- Misfiled - this issue doesn't belong in this issue tracker.
- Closed - The final resting place.
How do I help out?
Glad you asked!
Marking Duplicates
If you notice an newer issue that is a duplicate of an existing issue with a lot more comments, patches, or votes, feel free to choose "Resolve" and choose "Duplicate". But when you do this, please also choose "Link", and then say "This issue duplicates" and enter the main bug number. This lets everyone keep track of which bugs are duplicates of each other, and which bugs are reported more than others. This ensures that bugs that are often reported get the most attention, and also allows the duplicates to be reviewed from one central location, to ensure they are truly duplicates.
Resolving support issues
This one is best left to technically adept users that can spot the difference between a support issue and a bug -- it's not always a simple matter to figure out. You should at most "Resolve" a report that seems to be a support issue. "Resolving" an issue puts the responsibility back on the reporter to provide more information on why the report isn't a support issue, and is indeed a reproducible bug that an entire class of user experiences.
Resolving bugs that you can't reproduce
If you do exactly what they say in the bug, with the same environment, and can't reproduce the bug, you should resolve the bug. Be careful, if a bug is related to graphics rendering, and you do not have the same video card, for example, that is not the same environment and you can't make this determination. Again this is also best left to technically adept users.
Reproducing bugs
This one is very important! If you can create a step-by-step list to reproduce the bug in the bug report, this helps Linden Lab concentrate on bugs that can be verifiably fixed. Unless a bug can be reproduced, it is impossible to know if it has been fixed or not. Do what the bug reporter said they were doing, write a detailed step-by-step list of things you did to cause the bug to happen, and add it to the bug saying that you have successfully reproduced the bug. Such bugs with solid reproductions get higher priority in the development process, and help the Bug Triage Team work more efficiently.
What's the difference between "Fixed Internally" and "Fixed" resolutions?
It's simple:
- "Fixed" means the fix is available in the live Second Life release, right now.
- "Fixed Internally" means the fix has been made within Linden Lab and has not been released publicly yet. It may need to undergo extra care, like quality assurance, or requires merging from a branch, before being available to you. Think of it as a "We're almost there... coming soon!" notice.
Customizing preferences
If you want to show more issues per page or change the language JIRA's displayed in, Update User Preferences after logging in. (The email options currently have no effect, see WEB-58 for why.)
Who is WorkingOnIt Linden?
When an issue is being worked on, it may be assigned to "WorkingOnIt Linden" to mark its status. Any Linden has access to the account. See User:WorkingOnIt Linden for details.