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 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 raised a feature request before, then please read through all of the sections below.

If you have previously filed a feature request and are looking to refresh your mind on specific points, please use the links on the right to jump to your topic(s) of interest.

Table of Contents

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, the more likely it is to be considered by Linden Lab. Think of a feature request as a mini project proposal.
    • The scope of the request: 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.
    • 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 – those 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’s rare that resources are available for very special case needs.
    • If you can offer any required 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 feature request 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 (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 before filing a new feature request, 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).

You can receive e-mail updates on a Jira by clicking the Start Watching… (l) option (under People in the top right of a displayed Jira). The option will update to Stop Watching… (r), indicating you’re receiving updates. Click the option again to stop receiving updates; the option will revert to Start Watching.
  • 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 a feature request.

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:
    • Project is set to 1. BUG Project (BUG).
    • Issue Type is set to New Feature Request.
    • Use the drop-downs to set either, if required.
When filing a feature request, make sure Project is set to 1. BUG Project (BUG), and Issue Type to New Feature Request.

Completing and Submitting the Form

The Feature Request form is relatively straightforward, as outlines below:

  • Summary (required field): provide a concise summary of the feature request that can also be used as a title for it.
  • 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.
    • Limit this section to just one new feature idea, rather than multiple ideas.
    • 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.
  • Attachments: when providing attachments:
    • Make sure each attachment is clearly annotated with an understandable / relevant title.
    • Images of ideas / mock-up of UI, etc., are clearly and properly referenced / explained in the section of the form to which they relate.
    • Keep in mind that individual images can be no larger than 10 Mb in size.


  • Do not feel constrained be the default text box sizes: each will automatically expand as information is added.
  • 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.
  • 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.
Sample feature request, showing that they need not necessarily all be long and complex – click to enlarge, if required

When you are satisfied the form contains all the information you wish to include, click the Create button to file it with Linden 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 submission.

  • 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.
  • A proposal 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.
  • Use the New Feature Request form as a kind of “executive summary” of the idea, and submit it with the proposal attached as a PDF file or 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.

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 report is deemed to vague, is not easy to understand, doesn’t contain sufficient instructions to reproduce a bug, etc., it may be re-opened for more information to be added.
    • This will cause the Needs More Info flag to be displayed.
    • Reports 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 any update being missed.
The Needs More Info flag (arrowed) and the Info Provided button
  • 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.

Where Next?