Difference between revisions of "How To Propose A Viewer Feature"
| (5 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Before you request a feature == | == Before you request a feature == | ||
Before creating a request for a change to the Viewer, check the | Before creating a request for a change to the Viewer, check the [https://jira.secondlife.com/browse/VWR 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 == | == Adding comments to existing issues == | ||
You can add comments to Jira issues, but | You can add comments to Jira issues, but '''do ''not'' add comments that''': | ||
# 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. | #: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. | ||
# | # Say ''I saw this problem too'' unless you can provide a more reliable or simpler way to reproduce the problem (which are always welcome). | ||
# | # 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. | ||
# | # 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. | '''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. | ||
| Line 27: | Line 25: | ||
* What problem is solved 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. | '''Note that the user story does not describe a solution''' - it describes the problem and who has the problem. | ||
So '''do not say''': | So '''do not say''': | ||
| Line 36: | Line 34: | ||
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. | 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 | 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 Project|Snowstorm Team]] to discuss it. | ||
==Proposing solutions== | ==Proposing solutions== | ||
A good place to look for issues that we have flagged as especially suitable for contributions by open source developers is the [https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=14035 Open Development Candidates filter]. If you find an issue there that you'd like to provide an open source solution for, contact the [[Snowstorm Team]] to discuss it. | |||
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 | :'''It is much better for everyone if you get in touch 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), we will help you get your change reviewed, tested, and integrated. | |||
Latest revision as of 09:37, 7 December 2011
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:
- 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.
- Say I saw this problem too unless you can provide a more reliable or simpler way to reproduce the problem (which are always welcome).
- 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.
- 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 the Snowstorm Team to discuss it.
- It is much better for everyone if you get in touch 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), we will help you get your change reviewed, tested, and integrated.