OpenSolaris

Template Version: @(#)onepager.txt 1.31 07/08/08 SMI

This information is Copyright 2007 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:
        // Title of Project should be short - it will be used as the
        // subject line of electronic mail messages in addition to being
        // the official title of the project in the various dashboards and
        // databases.  If the project name doesn't hint at the broad purpose
        // of the project, append a word or two of explanation.  If there's
        // a new acronym, expand it.
        // Examples:
        // "MumbleFrotz: Excruciatingly Slow File Access"
        // "TLA: Threaded Library Access"

   1.2. Name of Document Author/Supplier:
        // The individual who are wrote this document and (it is assumed)
        // will be leading this project.

   1.3. Date of This Document:
        // MM/DD/YYYY

   1.4. Name of Major Document Customer(s)/Consumer(s):
        1.4.1. The Community you expect to review your project:
        1.4.2. The ARC(s) you expect to review your project:
                // Leave blank if you don't have any preference
                // This item is advisory only

   1.5. Email Aliases:
        1.5.2. Responsible Engineer:
        1.5.4. Interest List:

2. Project Summary
   2.1. Project Description:
        // A SHORT description of the project suitable for use on
        // dashboards and status rollups.  Think "1 paragraph" and not
        // "1 page".  See below for a longer, more detailed technical
        // description

   2.2. Risks and Assumptions:
        // Note any risks, incompatibilities, issues, or assumptions that
        // must be considered along with the proposal.
        // Include both technical and business risks.
        // Example: Incompatible changes to interfaces that others expect
        // to be stable may cause other parts of the SMI product stack to
        // break.  If this proposal exposes this risk, how can it be
        // managed/mitigated/avoided?

3. Business Summary
   3.1. Problem Area:
        // What problem or customer need does this project solve?

   3.2. Market/Requester:
        // Who needs the project?

   3.3. Business Justification:
        // Why is it important or valuable to do this project?

   3.4. Competitive Analysis:
        // Who are the current and anticipated players in this market?

   3.5. Opportunity Window/Exposure:
        // Time-to-market window, if any, and precision.

   3.6. How will you know when you are done?:
        // What will you measure to determine that the project is complete?
        //
        // This section is for explicit measurable customer CTQs that apply
        // to this specific feature proposal, not to the product as a whole.
        //
        // We *expect* every development team to meet their Feature,
        // Performance and Security and Testing goals, as well as getting
        // all required ARC and PAC review approvals, so don't put that
        // sort of metric here.

4. Technical Description:
    4.1. Details:
        // To the extent known, how is this going to be done?
        // If the source of implementation technology is external to Sun,
        // identify them here, too.
        // This information is used to get a feel for the
        // complexity and risk involved and to help understand
        // the architectural constraints that this project is working
        // under.  Try to present alternatives and show relationships to
        // existing or proposed projects/standards.

    4.2. Bug/RFE Number(s):
        // List any bug/rfe's which will be addressed by this proposed
        // change.

    4.3. In Scope:
        // Aspects that are in scope of this proposal if not obvious from
        // the above.

    4.4. Out of Scope:
        // Related aspects that are out of scope for this proposal if not
        // obvious from the above.

    4.5. Interfaces:
        // What interfaces are introduced, modified or deleted by this
        // proposal?  What interfaces does it import and export?  What are
        // the new exported interface's stability levels?
        // See http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/
        // (Think of Files/directories, Ports, DTD/Schema, admin tools and
        // config files, APIs, CLIs, etc, as well as incompatible or
        // unexpected changes that may affect consumers and/or customers)

    4.6. Doc Impact:
        // List any Documentation (man pages, manuals, service guides...)
        // that will be impacted by this proposal.

    4.7. Admin/Config Impact:
        // How will this change impact the administration of the product?
        // Identify changes to GUIs, CLI, agents, plugins...

    4.8. HA Impact:
        // What new requirements does this proposal place on the High
        // Availability or Clustering aspects of the component?

    4.9. I18N/L10N Impact:
        // Does this proposal impact internationalization or
        // localization?

    4.10. Packaging & Delivery:
        // What packages, clusters or metaclusters does this proposal
        // impact?  What is its impact on install/upgrade?

    4.11. Security Impact:
        // How does this proposal interact with security-related APIs
        // or interfaces?  Does it rely on any Java policy or platform
        // user/permissions implication?  If the feature exposes any
        // new ports, listeners, or any similar communication points
        // which may have security implications, note these here.

    4.12. Dependencies:
        // List all dependencies that this proposal has on other
        // proposals, components or products.  Include interface
        // specifics above in the interfaces section; list component
        // version requirements here.

5. Reference Documents:
        // List of related documents, if any (BugID's, RFP's, papers).
        // Explain how/where to obtain the documents, and what each
        // contains, not just their titles.  Identify any related projects
        // (by ID or case number, if possible).

6. Resources and Schedule:
   6.1. Projected Availability:
        // Dates in appropriate precision (quarters, years)

   6.2. Cost of Effort:
        // Order of magnitude people and time for the *whole* project, not
        // just the development engineering part.
        // You may wish to split the estimate between feature
        // implementation, implementing adminsitrative Interfaces, unit
        // tests, documentation, support training material, i18n, etc.

   6.4. Product Approval Committee requested information:
        6.4.1. Consolidation or Component Name:
        6.4.7. Target RTI Date/Release:
                // List target release & build and/or date.
                // RTI = Request to Integrate - when does *this* project
                // expect to be ready to integrate its changes back into
                // the master source tree?  We are not asking when the
                // component wants to ship, but instead, when the
                // gatekeeper/PM needs to expect your changes to show up.
                // examples: S8u7_1, S9_45, Aug 2002...
        6.4.8. Target Code Design Review Date:

   6.5. ARC review type:
                // Pick one of
                //   Standard
                //   FastTrack
                //   SelfReview
   6.6. ARC Exposure: open
       6.6.1. Rationale: Part of OpenSolaris

7. Prototype Availability:
   7.1. Prototype Availability:
        // Functional subset expected to be needed to leave "prototype"
        // stage.

   7.2. Prototype Cost:
        // Subset of Cost of Effort to leave "prototype" stage.