Difference between revisions of "Bug Tracker"

From Second Life Wiki
Jump to navigation Jump to search
m
m (jira->feedback.secondlife.com)
 
(38 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{Help|Bug Fixes=*}}
{{TOCright}}{{multi-lang}}
{{TOCright}}
''Is a feature not working as expected in your Second Life? You may have found a bug!''


First, two notes:
== What's a bug? ==


{| cellpadding="1" cellspacing="1" style="width: 70%; vertical-align: top;"
An unintended computer problem which happens for more than one person under the same conditions.
| colspan="2" style="padding: 0;" |
|-
| style="width: 100%; vertical-align: top;" |
{| border="0" cellspacing="0" cellpadding="0" width="100%"
| style="background-color:#fff;" width="0" |
{| style="width="30%"; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"
| rowspan="1" width="30%" colspan="2" height="37px" valign="top" style="background:#fff; border:2px solid #ABCDEF; border-bottom:0; padding:0; padding-right:1em; margin:0; -moz-border-radius-topright:1em" | [[Image:cartella_blu.jpg|none]] <div style="margin-top:-37px; padding-left:5px">[[Image:Info.png|36px]]</div><div style="padding-left:45px; margin-top:-29px; font-size:130%">'''Contributions'''</div>
|}
| style="border-bottom:2px solid #ABCDEF;" width="8" | &nbsp;
| style="border-bottom:2px solid #ABCDEF;" width="100%"| &nbsp;
|}
{| style="width:100%; margin-bottom:.5em; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"
| rowspan="1" width="100%" colspan="2" valign="top" style="background:#FFF; border:2px solid #ABCDEF; border-bottom:0; border-top:0; padding:0; margin:0" |
<div style="padding:10px; text-align: justify;">
All submissions to the site (JIRA included) are governed by the [[Project:Contribution_Agreement|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.
</div>
|-
| colspan="2" class="radius_bottom" style="border:2px solid #ABCDEF" | <div style="font-size:0">[[image:pix.gif|6px]]</div>
|}
|}


{| cellpadding="1" cellspacing="1" style="width: 70%; vertical-align: top;"
| colspan="2" style="padding: 0;" |
|-
| style="width: 100%; vertical-align: top;" |
{| border="0" cellspacing="0" cellpadding="0" width="100%"
| style="background-color:#fff;" width="0" |
{| style="width="30%"; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"
| rowspan="1" width="30%" colspan="2" height="37px" valign="top" style="background:#fff; border:2px solid #ABCDEF; border-bottom:0; padding:0; padding-right:1em; margin:0; -moz-border-radius-topright:1em" | [[Image:cartella_blu.jpg|none]] <div style="margin-top:-37px; padding-left:5px">[[Image:Info.png|36px]]</div><div style="padding-left:45px; margin-top:-29px; font-size:130%">'''Not a method for support'''</div>
|}
| style="border-bottom:2px solid #ABCDEF;" width="8" | &nbsp;
| style="border-bottom:2px solid #ABCDEF;" width="100%"| &nbsp;
|}
{| style="width:100%; margin-bottom:.5em; font-size:95%; text-align:left; padding:-2px; background:none" cellpadding="0" cellspacing="0"
| rowspan="1" width="100%" colspan="2" valign="top" style="background:#FFF; border:2px solid #ABCDEF; border-bottom:0; border-top:0; padding:0; margin:0" |
<div style="padding:10px; text-align: justify;">


<span style="color: red; font-weight: bold;">The JIRA Issue Tracker is ''not'' for technical support</span>, so please do '''not''' enter issues which would require a response tailored to your individual situation. If you're looking for account-specific help, please use our [http://secondlife.com/support support resources].
* '''<font color="red">NOT account-specific, support issues</font>''' - Individual situations that desire a response, such as a billing problem, are ''different'' For those, [http://secondlife.com/support visit our Support Portal].


Examples: for support, not the Issue Tracker:
== What's a bug report? ==
* "I can't change my tier"
* "I lost part of my inventory"
* "Someone stole my L$"
</div>
|-
| colspan="2" class="radius_bottom" style="border:2px solid #ABCDEF" | <div style="font-size:0">[[image:pix.gif|6px]]</div>
|}
|}


The '''Public issue tracker''' is located at http://jira.secondlife.com.  It is a searchable database used to organize issues (i.e. bugs and feature requests) submitted by the Second Life community.  There, you can help to provide information about issues you find when using the open source or standard versions of Second Life.  The information on this page will help you become familiar with this tool.
A description of a bug, shared by you with us. Useful bug reports are:


More precisely, JIRA is an issue-tracking project management tool made by [http://www.atlassian.com/software/jira Atlassian]. It is primarily used by the Second Life open source community and may be referred to as the "Public JIRA", "PJIRA", or just "JIRA", depending on the context.
* '''<font color="red">Easy-to-follow</font>''' - Ever given driving directions, where you emphasize landmarks to watch for? Bug reports should be like that: they have a sensible order and a friend can follow your steps.
* '''<font color="red">Reproducible</font>''' - Sadly, some bugs are like Bigfoot — hard to find evidence of. But many bugs happen reliably after following a series of steps. Confirm a bug so we can catch it in the wild.


== How it works ==
== Steps to create a good report ==
There are two main types of issues: bug reports and new features.
* A '''bug report''' is composed of a description of the problem AND a way to reproduce it.
* A '''new feature''' request is composed of a description and how the proposed feature should work.


# Both types of issues then get attention from other Residents, who can add better or simpler descriptions and reproductions.
With that in mind:
# Popular issues will accumulate Votes from other residents.
# Programmers in the open source community can attach "patches", or changes to the source code which address the issue.
# Votes, as well as events like [[bug triage]]s, help prioritize the issues.
# Those issues which are acknowledged by Linden Lab are "imported" into the Linden Lab internal copy of JIRA.  '''This means a bug will be investigated and worked on.'''


# '''[http://community.secondlife.com/t5/English-Knowledge-Base/How-to-report-a-bug/ta-p/733545 Read the article]''' about how to submit a bug.
# [https://feedback.secondlife.com Go to our Bug Tracker]
# Write a bug report including:
## '''Steps to follow'''
##:In as much detail as possible, describe a sequence of actions that any user can take to cause the problem to occur.  If particular conditions are required, such as being in a specific parcel or having particular permissions set for a group role, describe them carefully.  Before submitting your report, test your instructions by having someone else follow them to see if they see the problem. Making these instructions simple is good, but completeness is better than simplicity.
## '''Describe what you expected to happen'''
##: such as "the object should change to red" or "my avatar should be wearing the shirt"
## '''Describe what happened instead'''
##: If you are able to provide pictures, video, or other illustrations in addition to text, even better.
## '''Attach supporting information'''
##: If the problem is a viewer crash or a bad interaction with the server (not getting something you should have, or having an effect on the world that you should not have, for example), include the log files from your viewer as attachments.  Be sure that you specify as closely as possible the exact time at which the problem occur so that we can find any relevant information in the logs.  See [[Finding Log Files]] for how to find them.


After the issue gets Linden attention, others can still follow along what is the status of the issue:
The goal is to '''show developers what you see, so we can see it too, then hunt down and fix the bug'''.


* Once the changes are completed and awaiting release to the public, the bug is resolved to show '''"Fix Pending"'''.
== I'm not a geek and I need help! ==
* When the change is available in a new version of Second Life, it is resolved as '''"Fixed"'''.
Don't worry, everyone was new once. There's lots of discussion on the Bug Tracker where experienced Residents help new bug reporters.
* Generally, after being confirmed as fixed & done by Linden Lab's [[QA Portal|Quality Assurance Team]] and our community, the status is changed from "Resolved" to '''"Closed"'''.


== What if Second Life is having a widespread service issue '''right now'''? ==


In addition to "Fix Pending" and "Fixed", an issue can also be resolved if it appears to be a Duplicate of another issue, Unreproducible, Misfiled, not a bug, incomplete, etc.
Generally, login problems, teleport failures, and such are shown on our '''[http://status.secondlifegrid.net/ Grid Status Reports]''' and since we're already working on it, there's ''no'' need to file a bug report.


== What if the bug I found is '''really''' serious and shouldn't be shared? ==


== Create a bug report / feature request ==
'''[[Security_issues|Learn about our Security Issues steps]]''' for exploits that compromise real-life identity, destroy content, and other serious issues that need discretion to be fixed ASAP.
If you feel lost and don't know where to begin, watch this 15-minute video tour:


:<videoflash>Jofq8ClPfNg</videoflash>
== I reported a bug but it hasn't been fixed! Why? ==


=== Guidelines for a bug report ===
We fix many bugs, but it's unrealistic to expect that we'll fix ''all'' of them. Let's look at this closer:


{| style="background:#fffff0; width:85%; border:3px dashed #ABCDEF; padding:15px;"
* '''What do we know?''' We can't act on bugs that we can't reproduce or don't have enough info about. It's like telling the police a crime happened without evidence. (While bugs aren't criminals, they certainly cause us pain!)
|
* '''Is it enough of a priority?''' For example, an inventory loss bug that affects many Residents gets a much higher priority than a cosmetic glitch only noticed by a few.
* '''Always, always provide steps.''' (Number them!) We can ONLY investigate a bug if we can see how it happens. The easier we can reproduce the bug, the more quickly it can get fixed.
* '''What are the dependencies?''' Second Life is a complex system and we need to be sure, even if a bug ''seems'' simple, that fixing it won't create more bugs in related areas.
** For example, instead of saying "I crash when I upload things", the reproduction should be laid out in specific steps:
**: <font color="grey">1. I clicked File > Upload Image ($L10)...
**: 2. I chose a .TXT file instead of a .JPG file
**: 3. Click the Open button
**: 4. OBSERVE: I crash to my desktop.  No crash window comes up.</font>
** Try sending your writeup to a friend, to see if they can follow it. If your friend can follow the steps, chances are we can too!


* Consider attaching a screenshot, videos, crash logs, or any other related files (10MB limit each).  In the above example, you might consider attaching the file you tried to upload that caused the crash.
== How do I find out where bugs get fixed? ==


* '''Do not''' try to explain more than 1 issue in a single report. Each separate bug needs its OWN report to be tracked.
'''[[:Category:Release_Notes|Check the Release Notes]]'''. Each version contains blow-by-blow highlights of what was changed.


* '''Do''' search through other issues first, to ensure yours is not a duplicate.
== How do I report abuse on the Bug Tracker? ==


* When describing the bug, omit Resident names or other personally-identifying information. If the bug seems to affect only yourself or very few people, you should consider other ways to find technical support via the [http://support.secondlife.com support portal].
Unproductive discussion is discouraging, rude, and wastes time better spent fixing issues. We don't tolerate behavior like flaming which violates our [[Linden_Lab_Official:Community_Participation_Guidelines|guidelines]] — please report abuse so we can help keep the Bug Tracker a welcome environment! Thank ''you''!


|}
# In the Second Life Viewer (not on the web), select '''Help''' menu > '''Report Abuse'''.
# Fill in all the fields. Not all abuse categories apply to the Bug Tracker, but you may see an intolerant comment, for example.
# In the '''Details''' field, link directly to the abusive comment by clicking the link icon that appears when you hover over a comment, or specific issue where the comment is.
#: [[File:Bug_Tracker_comment_permalink.png]]
# Click '''Report Abuse''' and our Bug Tracker admins will check it out shortly.


=== Stay up-to-date ===
Depending on the severity of the abuse, the violator may get a warning or be permanently ''banned'' from the Bug Tracker and even all of Second Life.
# You can check the [[Release Notes]] to stay current with recent changes to Second Life.  Sometimes, you can discover the context around a new bug, or find that a change was intentional.  For example, not being able to sell your land for L$0 is a feature, not a bug!
# Also, you should [https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=3884 make sure your video drivers are up to date]. Hint for advanced users: The [http://www.omegadrivers.net/ Omega Drivers] are often-used modified versions of those drivers.


=== Determine if the issue has already been submitted ===
== Want to know more? ==


Before reporting issues of widespread system breakage, you should first see if there is any existing information by searching the [http://secondlife.com/community/support.php support resources], and look for the latest status reports on the [http://status.secondlifegrid.net/ Status Reports page].
After you've learned the essentials of bug reporting, give it some time to digest. Then:


Avoiding duplicate issues is very important. Sorting through duplicates wastes time and effort (for both Linden Lab staff and fellow residents), and it causes bugs and feature proposals to seem like they are getting less attention than they actually are. It is more effective to concentrate efforts about the same problem in the same reported issue, especially since more-active issues receive greater priority.
* '''[http://community.secondlife.com/t5/English-Knowledge-Base/How-to-report-a-bug/ta-p/733545 How to report a bug]''' - If your question wasn't answered above, see this. Highlights include:
** [[Linden_Lab_Official:Community_Participation_Guidelines|Community Participation Guidelines]]
** [[Bug_Tracker/Status|Resolution statuses]]
* '''[[:Category:Bug Tracker|Visit the Bug Tracker category]]''' - All pages related to the Bug Tracker.


After logging in, you will see the Dashboard. Here you have access to some search filters which give you access to the most up-to-date information on submitted issues. For example, you can click on ones which show all unresolved issues within each project, then begin a text search from there (by editing the filter). Of course you may simply run a new search from the '''Quick Search:''' box. Either way, it is best practice to search for issues you wish to report in several ways before submitting them!
[[Category:Bug Tracker]]
 
::If you find that your issue was already submitted, you can still do several things to help:
::* Leave a comment containing additional information or details
::* If it's a bug, possibly explain another way to reproduce the bug
::* Vote for the issue to express that you feel it is important.
::The more good, SPECIFIC information there is about an issue, the better chance it has for a quick resolution.
 
 
=== To submit a bug ===
To create a new bug, do the following:
# Click the "Create New Issue" link in the blue navigation bar towards the top of the screen.  (If you don't see this, make sure you are [[Issue_tracker/FAQ#How_do_I_log_in_to_the_Tracker.3F|logged in to JIRA]].)
# On the first page:
#* Select a '''Project''' that most closely matches the kind of bug you are submitting - see [[Issue_tracker/FAQ#What_are_Projects_and_Components.3F|Projects and Components]].
#* Select "Bug" as your '''Issue type'''.
#* Click "Next".
# On the second page:
## Enter a concise but informative '''summary''' (title) for the issue
## Select the '''priority''' (severity) of the bug.  For example, a "Showstopper" bug might render the program useless, but a "small" bug might be merely cosmetic.  Click the Help icon next to the dropdown for more details.
## Select '''components''' that narrow the scope of the bug.  You can select multiple components by Ctrl-clicking.
## Choose the '''versions''' that the bug effects.  You should only select those versions where you have observed the bug, and only select a "First Look" version if the bug ''only'' applies to First Look.
## Describe the computer '''environment''' in which the problem occured.  For example, if you have noticed that the bug only occurs with certain hardware or software configurations.
##* The best way to report this information is to paste the info that comes from inside Second Life viewer.  (Help menu > [[:Image:About_Second_Life_-_1.17.2.png|About Second Life...]])  Certain facts might be relevant (Windows vs Mac vs Linux machine, or graphics card model, or headset models for voice features).  If configuration truly doesn't matter, you can leave it blank.
##* 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, and be sure to include:
##* Steps (1,2,3...) to reliably reproduce the bug-- How to make the bug happen.  If you cannot identify the specific steps, describe what seems to lead to the bug.  Try to make this as simple as possible while still being specific enough to reproduce the bug.  Simpler reproductions make it easier to narrow down the causes.
##* OBSERVED results (what happens when the bug occurs)
##* EXPECTED results (what behavior you would have expected instead)
##* As a reminder: be as detailed as possible without including personal information!
## If you have a screenshot or video of the bug, or any other relevant file, you can attach it under '''attachment'''.  Note that it has a 10MB size limit per file.  You can also attach additional files later. (See [[Debug Help]] for various ways to hunt for such additional information.)
## If you are a programmer and are attaching a patch for the source code, enter the '''source version''' the patch is against and check the '''patch attached''' box.
# Finally, click "Create" to create the new issue.
 
=== To submit a new feature ===
The process is similar to submitting a bug, with the following differences:
 
* Select "New Feature" instead of "Bug" as your '''Issue type'''.
* Instead of a description how to reproduce, instead clearly describe the desired implementation and functionality that you would like in the new feature. Make sure it hasn't already been done — you can [http://blog.secondlife.com/ read our blog] to learn more about what we're doing next.
 
=== To submit a Security Issue! ===
* Please submit security-related issues and exploits directly to the security team.  ("Exploits" are bugs that could be used to get an advantage over others, unauthorized access to scripts, unauthorized copying or transferring or modifying of objects that you didn't create (also called 'permissions bugs'), and other bugs that could potentially cause a compromise of the grid or a resident's privacy.)
* For the fastest results, e-mail your security report to security@lindenlab.com.  See the article on [[security issues]].
 
== Be courteous ==
 
'''Note:''' The Second Life [http://secondlife.com/corporate/cs.php Community Standards] apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker. Pjira is neither a Forum nor a blog.  It is Also not the place for Policy discussion. It is a system used primarily by Linden Lab's Engineers and Developers. 
 
Examples of specific behavior or actions which may result in removal from the Issue Tracker:
* Using the Issue Tracker to promote a business, cause, blog, website or anything not directly related to the issue at hand.
*Personal Attacks
* Flaming, Trolling – Flaming (posting a comment that is intended to incite anger or directly attack a person or persons) and Trolling (a post with an intentionally contrary opinion written with the intent of inciting or getting argumentative opinions) are not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
* Private Discussions - Blogging your personal opinions or off-topic rants. The issue tracker is about finding solutions to bugs and problems. We love productive feedback. Please stick to the technical details of the matter at hand.
* Editing Wars - Repeated changes to a resolution, priority or classification of an issue within the issue tracker.
 
== Vote for issues ==
You can vote for new features and bugs that you wish to see fixed by Linden Lab, and [https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=10071 view all issues by # of votes]. JIRA uses [http://en.wikipedia.org/wiki/Approval_voting approval voting], so you can vote for as many (or few) issues as you'd like, and you get 1 vote per issue.
 
Votes are readily used as part of our prioritization process. Note that since we need to look at aspects such as feasibility and the time required for development, 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.  Check back to see if your issue has received comments or questions from Linden Lab.
 
When your issue has been fixed internally, it will be updated as well in the Issue Tracker (even before it is ready to ship in a new version).  So check your issues for changes on a regular basis.
 
 
== Status of your Issue ==
 
=== Available states ===
 
Here is how Linden Lab uses the various resolution states:
 
; 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 person who reported it, 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". Even though it was closed before, it is now reported as still a problem that needs attention.
 
; 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.
:; Fix Pending: means that the bug is fixed in a version of the code that should soon be publicly available.
:; Contact Support : the issue in the Pjira is one that needs to be handled through the support team and the resident needs to fill out a support ticket.
:; Won't Finish : means that the assignee or Linden Lab doesn't believe this issue should or will be fixed in any foreseeable future.
:; Duplicate : means that there's some other issue that describes the same problem/idea.
:; Expected Behavior : the issue being discussed is not a bug and functions as it does by design.
:; Needs More Info : this issue lacks enough information.  Please add that information or it CANNOT be investigated further.
:; Under Advisement : this is used by Linden Lab for issues that tend to fall more in the category of Policy rather than being just a technical bug.  This is used to let the community know that the Pjira has been viewed and is being discussed.
:; Cannot Reproduce : this means that following the stated steps still does not show the problem.  Perhaps there is additional settings/actions or factors that need to be true in order for the problem to occur.  Please provide an even more 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.  It's done!
 
== Frequently Asked Questions ==
 
See the [[Issue tracker/FAQ]] for answers to common questions!
 
== Searching ==
 
See the [[Issue tracker/Searching]] page for more help!
 
== How can I help Linden Lab track its bugs? ==
 
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.
 
=== Sorting issues in the wrong categories ===
 
If an issue is in the wrong category (i.e. a VWR issue that belongs in SVC) it should never be resolved as "misfiled." Instead, a comment should be left on [http://jira.secondlife.com/browse/WEB-566 WEB-566] listing the issue and where it should be belong. A JIRA volunteer will make sure it gets moved to the appropriate place.
 
== Related resources ==
Want to learn more about our Issue Tracker?
 
* '''[[Issue Tracker Forum Transcript]]''' - Info from Rob and Aric Linden on why we have an Issue Tracker, its behind-the-scenes workings, and answers to various questions.
* [http://www.atlassian.com/software/jira/docs/latest/introduction.html JIRA user's guide] by Atlassian, creaters of JIRA
 
[[Category: Issue Tracker]]

Latest revision as of 00:49, 27 January 2024

Is a feature not working as expected in your Second Life? You may have found a bug!

What's a bug?

An unintended computer problem which happens for more than one person under the same conditions.


  • NOT account-specific, support issues - Individual situations that desire a response, such as a billing problem, are different For those, visit our Support Portal.

What's a bug report?

A description of a bug, shared by you with us. Useful bug reports are:

  • Easy-to-follow - Ever given driving directions, where you emphasize landmarks to watch for? Bug reports should be like that: they have a sensible order and a friend can follow your steps.
  • Reproducible - Sadly, some bugs are like Bigfoot — hard to find evidence of. But many bugs happen reliably after following a series of steps. Confirm a bug so we can catch it in the wild.

Steps to create a good report

With that in mind:

  1. Read the article about how to submit a bug.
  2. Go to our Bug Tracker
  3. Write a bug report including:
    1. Steps to follow
      In as much detail as possible, describe a sequence of actions that any user can take to cause the problem to occur. If particular conditions are required, such as being in a specific parcel or having particular permissions set for a group role, describe them carefully. Before submitting your report, test your instructions by having someone else follow them to see if they see the problem. Making these instructions simple is good, but completeness is better than simplicity.
    2. Describe what you expected to happen
      such as "the object should change to red" or "my avatar should be wearing the shirt"
    3. Describe what happened instead
      If you are able to provide pictures, video, or other illustrations in addition to text, even better.
    4. Attach supporting information
      If the problem is a viewer crash or a bad interaction with the server (not getting something you should have, or having an effect on the world that you should not have, for example), include the log files from your viewer as attachments. Be sure that you specify as closely as possible the exact time at which the problem occur so that we can find any relevant information in the logs. See Finding Log Files for how to find them.

The goal is to show developers what you see, so we can see it too, then hunt down and fix the bug.

I'm not a geek and I need help!

Don't worry, everyone was new once. There's lots of discussion on the Bug Tracker where experienced Residents help new bug reporters.

What if Second Life is having a widespread service issue right now?

Generally, login problems, teleport failures, and such are shown on our Grid Status Reports and since we're already working on it, there's no need to file a bug report.

What if the bug I found is really serious and shouldn't be shared?

Learn about our Security Issues steps for exploits that compromise real-life identity, destroy content, and other serious issues that need discretion to be fixed ASAP.

I reported a bug but it hasn't been fixed! Why?

We fix many bugs, but it's unrealistic to expect that we'll fix all of them. Let's look at this closer:

  • What do we know? We can't act on bugs that we can't reproduce or don't have enough info about. It's like telling the police a crime happened without evidence. (While bugs aren't criminals, they certainly cause us pain!)
  • Is it enough of a priority? For example, an inventory loss bug that affects many Residents gets a much higher priority than a cosmetic glitch only noticed by a few.
  • What are the dependencies? Second Life is a complex system and we need to be sure, even if a bug seems simple, that fixing it won't create more bugs in related areas.

How do I find out where bugs get fixed?

Check the Release Notes. Each version contains blow-by-blow highlights of what was changed.

How do I report abuse on the Bug Tracker?

Unproductive discussion is discouraging, rude, and wastes time better spent fixing issues. We don't tolerate behavior like flaming which violates our guidelines — please report abuse so we can help keep the Bug Tracker a welcome environment! Thank you!

  1. In the Second Life Viewer (not on the web), select Help menu > Report Abuse.
  2. Fill in all the fields. Not all abuse categories apply to the Bug Tracker, but you may see an intolerant comment, for example.
  3. In the Details field, link directly to the abusive comment by clicking the link icon that appears when you hover over a comment, or specific issue where the comment is.
    Bug Tracker comment permalink.png
  4. Click Report Abuse and our Bug Tracker admins will check it out shortly.

Depending on the severity of the abuse, the violator may get a warning or be permanently banned from the Bug Tracker and even all of Second Life.

Want to know more?

After you've learned the essentials of bug reporting, give it some time to digest. Then: