This is the third part of a tutorial outlining how to use the Second Life JIRA. This section covers raising and submitting feature requests.
For further information in this tutorial, please see:
- Tutorial Introduction.
- Second Life JIRA Tutorial: Bug Reports.
- Second Life JIRA Tutorial: Security Exploits and Other Options.
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.
Raising A Feature Request
- Log-in to the Second Life JIRA using your Second Life log-in credentials.
- Click on +Create Issue (top right).
- The Bug Report form will be displayed.
- Click on the Issue Type drop down, and select New Feature Request.
- The Feature Request form is relatively straightforward, with three required parts: the “Summary”, “How” and “Why” – all of which are required.
- Summary: provide a summary description of the feature.
- 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.
- 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.
- 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.
- 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.
- If you want to submit more than one feature request, check the Create Another option.
- 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.
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.
Again, 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 request relates to improving a current capability, consider outlining the shortfalls of the capability for users, and how your idea improves things. Again, 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 again, if 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.
- It has been Accepted into the Lab’s internal JIRA system for tracking.
- The report 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.