Bug Tracker/ko

/ko

	Warning!
	This article contains an outdated translation. Please refer to the English version to access the latest updated content. If you would like to help updating the translation of this article, please join the Community Translation Project. set version=2

Update Needed

This article needs an update to reflect recent changes in the base article located at Issue tracker. When you're done with the update, change the {{Help/CODE|Parent=Issue tracker|BugFixes=*}} part to {{Help/CODE|Version=2|Parent=Issue tracker|BugFixes=*}}. Thank you for your help!

First, two notes:

Contributions     All submissions to the site 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. 6px

Not a method for support     The feedback.secondlife.com is not for technical support, 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 support resources. Examples: for support, not the Bug Tracker: "I can't change my tier" "I lost part of my inventory" "Someone stole my L$" 6px

The Public Bug Tracker is located at https://feedback.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.

How it works

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.

1. Both types of issues then get attention from other Residents, who can add better or simpler descriptions and reproductions.
2. Popular issues will accumulate Votes from other residents.
3. Programmers in the open source community can attach "patches", or changes to the source code which address the issue.
4. Votes, as well as events like bug triages, help prioritize the issues.
5. 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.

After the issue gets Linden attention, others can still follow along what is the status of the issue:

• Once the changes are completed and awaiting release to the public, the bug is resolved to show "Fix Pending".
• When the change is available in a new version of Second Life, it is resolved as "Fixed".
• Generally, after being confirmed as fixed & done by Linden Lab's Quality Assurance Team and our community, the status is changed from "Resolved" to "Closed".

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.

Create a bug report / feature request

If you feel lost and don't know where to begin, watch this 15-minute video tour:

<videoflash>Jofq8ClPfNg</videoflash>

Guidelines for a bug report

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. For example, instead of saying "I crash when I upload things", the reproduction should be laid out in specific steps: 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. 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. Do not try to explain more than 1 issue in a single report. Each separate bug needs its OWN report to be tracked. Do search through other issues first, to ensure yours is not a duplicate. 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 support portal.

Stay up-to-date

1. 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!
2. Also, you should make sure your video drivers are up to date. Hint for advanced users: The Omega Drivers are often-used modified versions of those drivers.

Determine if the issue has already been submitted

Before reporting issues of widespread system breakage, you should first see if there is any existing information by searching the support resources, and look for the latest status reports on the Status Reports page.

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.

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!

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:

1. 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 logged in to JIRA.)
2. On the first page:
   • Select a Project that most closely matches the kind of bug you are submitting - see Projects and Components.
   • Select "Bug" as your Issue type.
   • Click "Next".
3. On the second page:
   1. Enter a concise but informative summary (title) for the issue
   2. 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.
   3. Select components that narrow the scope of the bug. You can select multiple components by Ctrl-clicking.
   4. 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.
   5. 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 > 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.
   6. 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!
   7. 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.)
   8. 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.
4. 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 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 Community Standards apply to all areas of Second Life, including the Second Life Public Bug Tracker. Any Resident who disregards these guidelines may be banned from future use of the Bug Tracker.

Examples of specific behavior or actions which may result in removal from the Bug Tracker:

• Using the Bug Tracker to promote a business, cause, blog, website or anything not directly related to the issue at hand.
• Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Bug 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 Bug 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 Bug Tracker.

Vote for issues

You can vote for new features and bugs that you wish to see fixed by Linden Lab, 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 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 Bug 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 Bug Tracker.

Closed

The final resting place. It's done!

Frequently Asked Questions

See the Bug Tracker/FAQ for answers to common questions!

Searching

See the Bug 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 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 Bug Tracker?

• Bug Tracker Forum Transcript - Info from Rob and Aric Linden on why we have an Bug Tracker, its behind-the-scenes workings, and answers to various questions.
• JIRA user's guide by Atlassian, creaters of JIRA