How To Propose A Viewer Feature

Open Source Quick Links

• How To Propose A Viewer Feature
• How To Submit A Viewer Change
• Integration & Release Processes
• Feedback Portal
• Github

Before you request a feature

Before creating a request for a change to the Viewer, check the Viewer Issue Tracker to see if there is already an issue for it.

If you find something that is much like what you're interested in, it may be easier to modify the existing items than create new ones.

Adding comments to existing issues

You can add comments to Jira issues, but do not add comments that:

1. Just add your support for the issue, or complain that an issue has not been addressed, or that flame about how important it is.

   If there is a use case that is affected by the problem that is not already explained in the issue, please do add an explanation of that use case, but please stick to the facts.

2. Say I saw this problem too unless you can provide a more reliable or simpler way to reproduce the problem (which are always welcome).
3. That say I saw this on a different platform, or I saw this on a different version unless the issue already has some question in it from developers about that aspect.
4. Are about how to build a solution.

Jira is not a forum - it is a work tracking system. Putting in comments like those described above, or that are otherwise unproductive, just clutter it up and make the system harder to use for the job it is supposed to be doing.

If what you would like changed is a bug, then it should be reported as one - see the Issue Tracker.

Requesting new functionality

The best way to propose a change is to start with a User Story: a short (no more than a few sentences) statement of:

• Who is affected by the change
• What problem is solved by the change

Note that the user story does not describe a solution - it describes the problem and who has the problem.

So do not say:

Right clicking on an item in the Wearables tab of the clothing sidebar panel should offer the option to take off that item.

Instead say:

As a resident, I would like to be able to make changes to what items of clothing I am wearing now by displaying the current list of items and selecting items to remove.

If you believe that there are important principles that should be considered, such as user interface predictability or accessibility, then by all means mention them, but keep them separate from the basic statement of the problem and who has the problem.

A User Story can be entered in the Issue Tracker as a New Feature request, or you can post it as an email to the opensource-dev mailing list and contact the Snowstorm Team to discuss it.

Proposing solutions

A good place to look for issues that we have flagged as especially suitable for contributions by open source developers is the Open Development Candidates filter. If you find an issue there that you'd like to provide an open source solution for, contact Oz Linden either by coming to one of his User Group meetings or by email to discuss it.

It is much better for everyone if you contact Oz before actually doing substantial work on an issue. There may be reasons (such as potential overlaps with work being done by others either inside or outside Linden Lab) why it may be a bad time to work on certain issues.

For any non-trivial fix, and certainly for any new feature, prepare a description of how you propose to address an issue, so that it can be reviewed and we can give you feedback on it before you've invested implementation time. This will significantly ease the process of getting the review of any implementation done, and might save you quite a lot of work on things we'll only ask you to change anyway.

Once the proposed solution has been accepted (which may be very quick for simple or obvious issues, or may take some time to evolve into a mutually acceptable solution), Oz will help you get your change reviewed, tested, and integrated.