Difference between revisions of "Feature Requests"
Jump to navigation
Jump to search
| Line 26: | Line 26: | ||
* The request will introduce security issues. | * The request will introduce security issues. | ||
* Scope of work is too great. | * Scope of work is too great. | ||
* A Linden didn't even read it, or couldn't be bothered talking to you about it. | |||
[[Category:Bug Tracker]] | [[Category:Bug Tracker]] | ||
Revision as of 06:25, 30 October 2016
Do you have suggestions for a new or enhanced feature? We're always looking for new ideas. Please let us know what you would like to see done.
The best place for your feature requests to get noticed is in JIRA Bug Tracker.
How to Write a great Feature Request
- Tell us about the specific functionality you're hoping to see. Describe both the current behavior and desired behavior in as much detail as possible.
- Provide Supporting Materials. This can be done with snapshots, videos, example code, etc. Again, the more information you provide, the better!
- What are the benefits of your Feature?
What Happens Next
Once your Feature Request has been submitted, it will join the queue for a team of Lindens to review. Please be patient... Depending on the nature of your request, it may require members of multiple teams to review.
Why wasn't my Feature Request Accepted?
Please be reassured this isn't personal! We understand, and appreciate, that you put a lot of thought into these proposals, and we consider them seriously. Some feature requests we simply cannot do. Here are some of the reasons why:
- Our internal architecture doesn't allow it.
- It will break existing content.
- It is not scalable.
- The request will introduce security issues.
- Scope of work is too great.
- A Linden didn't even read it, or couldn't be bothered talking to you about it.