Template Version: @(#)onepager.txt 1.36 10/02/16 SMI
Copyright 1994, 2010, Oracle and/or its affiliates. All rights reserved.
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 Fast 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.3.1. Date this project was conceived:
// If a project is considered "done" when it integrates
// into a component's source tree, this would be the
// date when it "started". By definition, it will be
// on or before the date found in 1.3.
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 and 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://hub.opensolaris.org/bin/view/Community+Group+arc/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.
