IntroductionThis tutorial has been written as a guide to filing SL bug reports and feature requests using the Second Life Jira. It comprises two parts: Bug Reports:
Feature Requests (this section):
Both sections are self-contained and can be bookmarked / referenced independently of one another for ease of use. However, to further assist in finding information, the table of contents on the right can be found in both part of the tutorial, and can be used to reference specific sections of either one. |
Table of Contents
|
Acknowledgements and Thanks
I would like to express my thanks to the following people for their input into this tutorial and for sanity checking the contents: Alexa Linden, Grumpity Linden, Kyle Linden, Soft Linden and Whirly Fizzle.
What is the Jira For?
As noted above, the Jira is primarily for:
- Filing reports on bugs that impact Second Life (covering the viewer, the simulator and the web), and which in doing so adversely impact the user experience.
- Putting forward suggestions on features and capabilities that might enhance Second Life for users.
The Jira can also be used by third-party viewer (TPV) developers to have their viewer added to the TPV Directory, or for reporting TPVs that may be violating the TPV Policy / Second Life Terms of Service. Both of these options fall outside the scope of either part of this tutorial.
When using the Jira, please keep in mind:
- It should not be used to report problems which are specific to you or for general enquiries about things like log-in issues; tier payments; running Second Life on a specific hardware configuration, land issues, and so on.
- For these types of issues, please use the Second Life Support Portal and / or the forums.
- If you believe the bug presents a security risk (such as allowing griefing or exposing sensitive information), you should use the SEC bug report, details of which can be found in Security Exploits.
- When adding comments to a report / feature request (see Commenting on filed requests), these should focus on technical feedback / input pertinent to the issue/ request being made. Personal opinion or general discussions on a bug / feature request can be held through the Second Life forums.
Feature Request Overview
Feature requests are ideas for the technical improvement of Second Life that are submitted to Linden Lab by users. While not all are accepted / actioned, many enhancements have come about as a direct result of submitted feature requests. However, when considering filing a feature request, some basic points need to be considered:
- The chances of how and when a feature request being adopted depends on a number of factors, including:
- How well the case is written up: the more informed a feature request is, the more likely it is to be considered by Linden Lab. Think of a feature request as a mini project proposal.
- Scope: requests that are focused on achieving a single, clearly defined goal are more likely to be viewed positively than requests that call for sweeping (and potentially vague) changes to SL.
- It is better to file multiple feature requests on ideas / suggestions than to try to cram multiple ideas into a single request.
- Remember, the Lab need to be able to digest your idea(s) and be able to see how they might fit with current work being carried out, or might fit with future work being planned. Keeping to one idea per feature request helps with this.
- How the idea fits with the current roadmap of improvements: the Lab is constantly working to improve Second Life, and look at feature requests in terms of what is on their current roadmap of improvements. Requests that match what is planned many be implemented sooner than others.
- How well it benefits the entire Second Life community: LL is especially interested in ideas that improve everybody’s experience. It is rare that resources are available for very special case needs.
- Offer of code (viewer feature requests only): if a request for a new viewer feature includes code supplied under a contribution agreement, the feature might be adopted ahead of others / alongside of the Lab’s own work in enhancing the viewer, again allowing for the above points.
- Use images and attachments.
- Providing a mock-up image of how you’d like a new panel in the viewer to appear, or a diagram showing the flow of how a new feature would be used, etc., can be a lot clearer than a wall of text.
- If the idea warrants it, don’t be afraid to provide an outline in the Feature Request form and then provide a more comprehensive project proposal as an attachment (see Using a Proposal, below).
Before You File a Feature Request
It is possible that the idea you have may already be the focus of a feature request, so please consider using the Jira search capability to look for similar ideas before submitting a request.
If you find that a feature request already exists for the idea, you can opt to click the Watch option (top tight of a feature request, under People) to receive updates to the Jira via e-mail (you can uncheck Watch should you no longer wish to receive these updates).
Filing A Feature Request
Setting the Project and Issue Type
- Log-in to the Second Life Jira using your Second Life log-in credentials.
- Click on the blue Create button in the top menu bar.
- Check the top of the form and make sure:
Completing the Form
- Summary (required field): provide a concise summary of the feature request (also forms the request title).
- If the request is related to a specific project (e.g. EEP), please include the project name at the start of the summary in square braces (e.g. [EEP]).
- How Would You Like This Feature To Work (required field): provide an outline of how your proposed feature should work.
- Be as clear and concise as possible.
- Try to provide a step-by-step guide to how the feature would work.
- If the feature is viewer-related and requires a new or updated UI panel, offer image mock-ups of how it should look using the Attachments option, and reference them here.
- Why Is This Feature Important To You? How Would It Benefit The Community? (required field): describe why the feature would be useful to you / to Second Life users in general.
- Be as clear as possible.
- If the request is intended to overcome a specific shortfall in SL, outline what that shortfall is.
- If there are a number of potential benefits, list them in turn.
- If possible, include a use case on how the featured would be used, if implemented.
- Include any relevant images that may help explain things, and reference them here.
- Attachment: use this option to add any suitable attachments to the request (e.g. mock-ups of new / updated viewer panels).
- Multiple images can be submitted, but ensure each is clearly labelled / annotated and properly referenced in the relevant text fields in the first part of the feature request form.
- Keep in mind that individual images can be no larger than 10 Mb in size.
Note that feature requests do not have to be long or complicated. The image below illustrates a simple, straightforward request that has been accepted by the Lab.
Using a Proposal
If you are offering a significant feature request – such as a new user interface option for users, a new viewer or simulator capability, etc., – consider offering a complete proposal to the Lab, submitted as an attachment to a feature request.
A proposal can:
- Let you summarise your idea in the Feature Request form, and then go into greater detail in your proposal.
- Allow you to structure your idea clearly, and present it logically and together with related images (UI mock-ups, etc.).
Keep your proposal to a single idea, and don’t forget to explain how it should work and why it would be of benefit. It doesn’t have to be a treatise, just so long as it explains the idea, why you believe it is important and how it would benefit the SL community.
A proposal can be attached to a feature request as a .PDF file or included as a link to a publicly viewable Google Docs file.
For a good example of a feature request see the Hover Height proposal submitted to Linden Lab in 2015, and which led to the inclusion of the “on the fly” hover height adjustment capability in the viewer.
Submitting Your Feature Request
When you have confirmed the information is correct and as clear as possible, and any images / files you wish to include are attached, click the Create button at the bottom right of the form to file your bug report.
Refer to What Happens Next?, below, for information on what happens to a filed bug report.
Commenting on Filed Requests
Sometimes after filing a feature request, there may be additional information you wish to add. You can generally do this via the Comment button at the bottom of a feature request page.
- Who can comment on a feature request depends on a variety of factors, including general permissions, the security level for the report (Public or Triagers and Reporters), together with the current status of the report (Open, Needs More info, Accepted).
- If the Comment button is unavailable, you will need to request permission to make Jira comments. Send an e-mail to letmein-at-lindenlab.com, giving your avatar name and a clear reason for requesting access.
- Note that you do not need comment rights in order to file bug reports or feature requests.
What Happens Next?
The Jira Workflow
A submitted feature request follows a set workflow, as shown in the diagram below.
- Awaiting Review: when you submit a feature request, it enters a queue for review (triage) by the Lab’s QA and Product teams.
- Triage: incoming requests are triaged on a weekly basis. The outcome is generally one of the following, as indicated in the status area of the report:
- Needs More Information: if the report is vague or not easy to understand or doesn’t contain sufficient information needed to understand the request, it will be flagged by the Lab as requiring more information from the reporter.
- This sets the Needs More Info flag on the feature request, and in addition a comment is generally provided by the Lab as to what is required.
- The reporter should review the request and any comment(s) recorded by the Lab and attempt to provide the missing information.
- Information Provided: when additional information has been added to a request, it is essential the Info Provided button is clicked. This will update the bug report to inform the Lab that the information has been supplied. Note that a failure to click the button could result in a delay in a request being further actioned.
- Needs More Information: if the report is vague or not easy to understand or doesn’t contain sufficient information needed to understand the request, it will be flagged by the Lab as requiring more information from the reporter.
- Accepted: the feature request is accepted by the Lab and cloned into their internal JIRA system for tracking.
- However, Accepted does not mean a feature request will acted upon immediately. Rather, it may mean the Lab are sufficiently interested in the idea to keep track of it, but implementation may be held until such time as it fits / can be slotted into the SL development road map.
- Sometimes, on further reviewing a bug report / feature request, Linden Lab may request even more additional information, and will re-open the original (see Needs More Information, above).
- Once an accepted report / feature request has been implemented, the originating Jira will be Closed with a status of Resolved.
- Closed: the request is not to be taken any further. Typically, a feature request will be closed and annotated with one of the following reasons:
- Duplicate: there’s another feature request covering the same idea.
- Unactionable: the described feature has been declined by the Linden Lab feature request review team.
- Not Applicable: the reporter has decided to close the issue.
- Resolved: the request has been implemented.
Inara Pey: Living in a Modemworld 