Second Life JIRA Tutorial: Feature Requests

This is the third part of a tutorial outlining how to use the Second Life JIRA. It covers raising and submitting feature requests. For other lessons in this tutorial, please refer to the JIRA Tutorial Pages links in the table of contents.

If you have not filed a feature request before, then please read through all of the sections below.

Table of Contents

If you have previously filed a feature request and are looking to refresh your mind on specific points, please use the table of contents to navigate to your specific topic of interest.

Feature Request Overview

Feature requests are ideas for the technical improvement of Second Life that are submitted to Linden Lab for consideration. Contrary to some thinking, a good number of Second Life enhancements have come about as a direct result of submitted feature requests. However, 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 in terms of why it is being suggested, what it would do, how it might work, the benefit it would bring to Linden Lab and the user base, how it might help users, etc. In this respect, think of a feature request as a mini project proposal.
    • How feasible the request is. The more feasible the request is, then the more likely it is to gain consideration. A feature  request to “completely overhaul the rendering system to make it look like modern games” isn’t likely to gain consideration because a) it is vague, and b) such a dramatic update to SL isn’t likely to be considered feasible.
    • How the idea fits with the current roadmap of improvements. If you see the Lab is working on a specific aspect of SL and you submit a clearly defined feature request that helps enhance that work in some way, then it potentially stands a better chance of being adopted and possibly implemented. This doesn’t mean that feature requests which don’t fit the current roadmap “won’t” be considered – just that they might take longer to see the light of day if they are adopted.
    • How well it benefits the entire Second Life community. Lindens are especially interested in ideas that improve everybody’s experience. It’s rare that resources are available for very special case needs.
    • If you can offer the code under a contribution agreement (viewer features only). If you submit a feature request for the viewer and can supply the required code to Linden Lab for testing / integration, then the feature might be adopted ahead of others / alongside of the Lab’s own work in enhancing the viewer.
  • Feature requests should be focused.
    • 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 JIRA helps with this.
  • Use images and attachments.
    • Pictures can be worth a thousand words 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 form and then provide a more comprehensive project proposal as an attachment.

Before You File a Feature Request

It is possible that the idea you have may already be the focus of a feature request, so before filing a bug report please consider using the JIRA search capability to look for similar issues before submitting a bug report.

If you find that a bug report already exists for the issue, you can opt to click the WATCH option (top tight of a bug report, under PEOPLE) to receive updates to the JIRA via e-mail (you can uncheck WATCH should you no longer wish to receive these updates).

You can receive e-mail updates on a JIRA by clicking the Watch (l) option (under People in the top right of a displayed JIRA). The option will update to Watching (r), indicating you’re receiving updates. Click the option again to stop receiving updates; the option will revert to Watch. Note that the Vote option does not have an influence on how JIRAs are handled by the Lab.
  • If the COMMENT button is unavailable, you will need to request permission to make JIRA comments. Send  an e-mail to, giving your avatar name and reason for requesting access.
  • Note that you do not need comment rights in order to file bug reports or feature requests.

Filing A Feature Request

  1. Log-in to the Second Life JIRA using your Second Life log-in credentials.
  2. Click on +Create Issue (top right).
  3. The Bug Report form will be displayed.
  4. Click on the Issue Type drop down, and select New Feature Request.
Use the JIRA Issue Type drop-down to select and display the New Feature Request Form
  1. The Feature Request form is relatively straightforward, with three required parts: the “Summary”, “How” and “Why” – all of which are required.
  2. Summary: provide a summary description of the feature.
  3. How: outline how the feature you’re requesting should work. When completing it:
    • Be as clear and concise as possible; limit your request to one new feature idea.
    • If possible, give a step-by-step outline of how the feature would work. Imagine you are giving the Lab a set of instructions they might follow to implement the idea.
    • If you are proposing a new feature that requires an new or updated user interface option, try to offer one (or more, as required) mock-ups of the floater(s) / panel(s) the feature will use, and explain what they are / how they would work.
    • If useful / appropriate, offer a use-case illustrating how the feature / update will work when implemented.
    • When including images, make sure they are properly annotated / referenced in this section.
  4. Why: describe why the feature / update would be useful to you and Second Life users in general. Again, be as clear and concise as possible, and if you include an images related to the “why”, make sure they are clearly annotated / referenced in this section.
  5. Note that scroll bars will automatically appear on the right of each text box as you enter text – so don’t feel you are limited by the size of either text box.
The New Feature Request form
  1. Optional images can be added the Attachment Browse button – you can include multiple images with a single feature request – but make sure they are clearly annotated within the How section. Note individual files can be no larger than 10 Mb.
  2. If you want to submit more than one feature request, check the Create Another option.
  3. When you have confirmed the information is correct and as clear as possible, and any images / files are attached, click the Create button to submit your feature request.
Sample feature request, showing that they need not necessarily all be long and complex – click to enlarge, if required

Using a Proposal

If you are offering a significant feature request – such as a new user interface option for users, or a new approach to using a capability within the viewer – consider offering a complete proposal to the Lab, submitted as an attachment to a feature request submission.

  • Keep the proposal to a single idea, and structure it as clearly as possible – how it would work, why it would be of benefit, etc.
  • If the proposal relates to improving a current capability, consider outlining the current shortfalls of the capability for users, and how your proposal improves things.
  • If you are proposing changes to the viewer user interface, consider including mock-ups of how your idea would look.

The advantage of this approach is that you can take the time to think-out and structure your idea, take the time to consider how you present it to the Lab, and can then use the New Feature Request form as a kind of “executive summary” of the idea, and submit it with the proposal as an attachment (e.g. in .PDF format) or provide it as a Google document available for public viewing and include a link to the document in the New Feature request form.

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, is regarded as a good example of a feature request proposal. So if you’re submitting a significant feature request of a similar nature, consider using it as an example.

What Happens Next?

Submitted feature request are tiraged (reviewed and assessed) generally once a week. This will result in one of three likely actions:

  • It Needs More Information: if the request is deemed to vague, is not easy to understand, covers too many different ideas or doesn’t contain sufficient information on how it would work, how it would benefit users, etc., it may be re-opened for more information to be added. Requests in this state will be periodically checked by the Lab to see if sufficient information has been supplied.
    • When providing additional information, reporters must click the Info Provided button. Failure to do so could result in the updating going unnoticed.
When providing additional information on a JIRA, remember to click the Info Provided button, located at the top of the JIRA report, just above the title
  • It gets Accepted and cloned into the Lab’s internal JIRA system for tracking.
  • It is Closed with no further action. The reason for it being closed may be given as one of the following:
    • Duplicate: there’s another JIRA making the same request.
    • 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.

When a Feature Request Is Accepted

Please note that when a Feature request is Accepted, it does not mean it will be 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.