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:

• Product Backlog to see if we already have some version of the proposal.
• Viewer Issue Tracker to see if there is already an issue for it.

Most things that appear in one should appear in the other in some form, but there may be exceptions and looking in both places will increase your chances of finding it if it's there. 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 observe the following rules:

1. Do not add comments that 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.
2. Do not add comments that 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. Do not add comments 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. Do not add comments 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, the 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 then come to one of the Snowstorm Project Team office hours to discuss it.

Proposing solutions

If you find an issue in the tracker or the Product Backlog that you'd like to provide an open source solution for, contact Oz Linden either by coming to one of his Office Hours or by email to discuss it. He'll help you work out how best to present your proposal and get it reviewed.

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), we can integrate your work into one or more Snowstorm Project sprints.