Example Feature

(Guideline text is in italics like this.)

(Please do not edit this example directly; instead, make a copy of the page from the edit window, and start your own page under the Feature_Proposals section!)

Basic Info

(You should be able to completely fill out this section during your first edit of your proposal.)

• Summary: (A one- or two-sentence description of what your feature does. Be VERY brief!)
• Developer Sponsor(s): (Your Wiki name, email, etc.)
• Start Date: (The date when you first started work on this feature)
• Branches Targeted: (e.g. trunk, 0.6.x, etc.)
• Commercial: (Yes/No: Is this feature directly driven by a business or commercial venture running on OpenSimulator?)
• Code Repository: (A repository URL (SVN or Git preferred) where interested parties can get your code. If you haven't committed anything yet, that's fine; but please at least create your repository and make it public before you submit your proposal.)

High-Level Design

Idea

(This is where you pitch your idea in detail. Paragraphs of prose, bullet points, and so forth are appropriate here. At a minimum, you should cover the following bases:

• What the purpose of the feature is
• Why users would want to use the feature
• Describe how users would use the feature in the ideal scenario
• Describe the status quo, i.e. what users currently have to live with)

Criteria

(This is where you draw a box around the bounds of your project, letting us know where your feature starts and ends, how it impacts the rest of the system, etc. A few examples are provided.)

• Scope: (Define what is and isn't within the scope of work you are willing to take on as part of the feature implementation.)
• Software Requirements: (Mention any new third-party dependencies, version bumps or build system changes that would be necessary for implementation.)
• Impact: (List which existing modules in the code-base may have to be modified to integrate with your feature.)
• Blockers: (List any open issues, outside the scope of your feature, which may be required or strongly recommended before your feature can integrate with the rest of the system. Bonus points for links to Mantis bugs!)

Implementation Overview

(This is where you can start to think about things like: naming your module(s) and interface(s), defining an API, and describing how other modules in the system should change to work with your code. Including Unified Modelling Languages (UML) diagrams for complex systems is much appreciated!)

User Experience

(How will the user interact with your feature? Assume that there is a compiled binary distribution of OpenSim with your fully-implemented feature, and assume an audience of a reasonably-experienced OpenSim sysadmin who is not necessarily experienced with software development. You should document things like console commands, configuration settings, script functions, etc. in this space.)

Low-Level Design

(Your actual code will be in your repository, but you can include additional details on design here if you want. For example, if your module exposes a complex API that other modules will want to use, you can list that API here. Other developers may be interested in working with you to revise the API before you start working on the implementation.)