|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.
|Table of Contents
If you have previously raised 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 raise 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 Raise a Feature Request
It is possible that the idea you have may already be the focus of a feature request, so before raising a 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).
- 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 reason for requesting access.
- Note that you do not need comment rights in order to raise bug reports or feature requests.
Raising A Feature Request
- 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.
- 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” being required fields. Completing these sections is summarised in the image below.
- When providing images for the “How” and “Why” sections, use the attachment option in the form and, as noted in the image above, please make sure:
- They are clearly annotated with an understandable / relevant title.
- They are clearly and properly referenced / explained in the section of the form to which they relate.
- Images are no larger than 10 Mb in size.
- 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.
- 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.
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, 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 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.
- 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.