Difference between revisions of "Bug Tracker/Help LL"
m (moved Issue Tracker/Help LL to Bug Tracker/Help LL: http://blogs.secondlife.com/community/technology/blog/2010/09/07/introducing-the-new-jira) |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Here's how you can help Linden Lab track and fix bugs. | {{TOCright}} Here's how you can help Linden Lab track and fix bugs. | ||
== Submit patches == | == Submit patches == | ||
| Line 6: | Line 6: | ||
{{KBcaution|Remember that all contributions are governed by the [[Project:Contribution_Agreement|Second Life Project Contribution Agreement]].}} | {{KBcaution|Remember that all contributions are governed by the [[Project:Contribution_Agreement|Second Life Project Contribution Agreement]].}} | ||
== | == '''[[Quality_Assurance|Learn about the Quality Assurance process]]''' == | ||
'''[[Quality_Assurance| | |||
== Vote for issues == | == 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]. | 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]. The Issue Tracker 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. | Votes are readily used as part of our prioritization process. Keep in mind 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. | ||
== Marking Duplicates == | |||
If you notice an newer issue that's a duplicate of an existing issue with a lot more comments, patches, or votes, feel free to choose '''Resolve''' with a [[Issue_Tracker/Status|status]] of '''Duplicate'''. But when you do this, please also choose '''Link''', then specify the main bug #. This reduces confusion and ensures that bugs that are often reported get the most attention. It also allows the duplicates to be reviewed from one central location, to show they're truly duplicates. | |||
== Resolving support issues == | |||
=== Reproducing bugs === | If you're not sure, learn from and leave this to technically experienced Residents who can spot the difference between a [http://secondlife.com/support 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 substantiate otherwise. | ||
This one is very important! | |||
== Resolving bugs that you can't reproduce == | |||
This is also best left to the technically adept. If you follow the same steps in an issue with the same environment, yet can't reproduce the bug, you should resolve the bug. ''Be careful:'' for example, if a bug is related to graphics rendering and you don't have the same graphics card, that's ''not'' the same environment and you can't make this determination. | |||
== Reproducing bugs == | |||
<font color="red">'''This one is very important!'''</font> 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's impossible to know if it has been fixed or not. Do what the bug reporter said they were doing, write a better step-by-step list of things you did to cause the bug to happen, and add it to the bug — make it clear that you've successfully reproduced the bug. Such bugs with solid reproductions get higher priority in the development process, and help [[bug triage|bug triages]] to work more efficiently. | |||
=== Sorting issues in the wrong categories === | === Sorting issues in the wrong categories === | ||
If an issue is in the wrong category ( | If an issue is in the wrong category (e.g., a VWR issue that belongs in SVC), it should ''never'' be resolved as '''Misfiled'''. Instead, [http://jira.secondlife.com/browse/WEB-566 leave a comment here] listing the issue and where it should belong. A volunteer will move it to the appropriate place. | ||
Latest revision as of 08:37, 8 September 2010
Here's how you can help Linden Lab track and fix bugs.
Submit patches
Do you have coding skills? Visit our Open Source Portal to learn more!
 |
Important: Remember that all contributions are governed by the Second Life Project Contribution Agreement. |
Learn about the Quality Assurance process
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. The Issue Tracker 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. Keep in mind 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.
Marking Duplicates
If you notice an newer issue that's a duplicate of an existing issue with a lot more comments, patches, or votes, feel free to choose Resolve with a status of Duplicate. But when you do this, please also choose Link, then specify the main bug #. This reduces confusion and ensures that bugs that are often reported get the most attention. It also allows the duplicates to be reviewed from one central location, to show they're truly duplicates.
Resolving support issues
If you're not sure, learn from and leave this to technically experienced Residents who 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 substantiate otherwise.
Resolving bugs that you can't reproduce
This is also best left to the technically adept. If you follow the same steps in an issue with the same environment, yet can't reproduce the bug, you should resolve the bug. Be careful: for example, if a bug is related to graphics rendering and you don't have the same graphics card, that's not the same environment and you can't make this determination.
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's impossible to know if it has been fixed or not. Do what the bug reporter said they were doing, write a better step-by-step list of things you did to cause the bug to happen, and add it to the bug — make it clear that you've successfully reproduced the bug. Such bugs with solid reproductions get higher priority in the development process, and help bug triages to work more efficiently.
Sorting issues in the wrong categories
If an issue is in the wrong category (e.g., a VWR issue that belongs in SVC), it should never be resolved as Misfiled. Instead, leave a comment here listing the issue and where it should belong. A volunteer will move it to the appropriate place.