Difference between revisions of "How To Propose A Viewer Feature"
(Created page with 'Before creating a request for a change to the viewer, there are two places you should check: * Look at the Product Backlog to see if we already have some version of the propo...') |
Rand Linden (talk | contribs) |
||
| Line 1: | Line 1: | ||
Before creating a request for a change to the viewer, there are two places you should check: | Before creating a request for a change to the viewer, there are two places you should check: | ||
* Look at the [ | * Look at the [https://spreadsheets.google.com/ccc?key=0AnxJWUubGIsodENWR2xPNW5kUl9veXJmS0VDOUN4S0E&hl=en Product Backlog] to see if we already have some version of the proposal. | ||
* Look at the [https://jira.secondlife.com/browse/VWR Viewer Issue Tracker] to see if there is already an issue for it | * Look at the [https://jira.secondlife.com/browse/VWR 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. | (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. | ||
| Line 32: | Line 32: | ||
==Proposing Solutions== | ==Proposing Solutions== | ||
If you find an issue in the tracker or the [ | If you find an issue in the tracker or the [https://spreadsheets.google.com/ccc?key=0AnxJWUubGIsodENWR2xPNW5kUl9veXJmS0VDOUN4S0E&hl=en 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. | 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. | ||
Revision as of 15:16, 23 August 2010
Before creating a request for a change to the viewer, there are two places you should check:
- Look at the Product Backlog to see if we already have some version of the proposal.
- Look at the 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.
You can add comments to Jira issues, but observe the following rules:
- 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.
- 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).
- 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.
- 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.