Difference between revisions of "How To Propose A Viewer Feature"

From Second Life Wiki
Jump to navigation Jump to search
 
(6 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.
* [http://jira.secondlife.com/secure/VersionBoard.jspa?selectedProjectId=10244 Product Backlog] to see if we already have some version of the proposal.
* [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.
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 observe the following rules:
You can add comments to Jira issues, but '''do ''not'' add comments that''':
# 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.
# Just add your support for the issue, or complain that an issue has not been addressed, or that flame about how important it is.   
# 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).
#: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.
# 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.
# 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 about how to build a solution.
# 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 26: 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 35: 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 then come to one of the [[Snowstorm Project|Snowstorm Project Team]] office hours to discuss it.
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==


If you find an issue in the tracker or the [http://jira.secondlife.com/secure/VersionBoard.jspa?selectedProjectId=10244 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.
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 can integrate your work into one or more Snowstorm Project sprints.
:'''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:

  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 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.