Wiki code for Reference: Sun's current internal ARC process

Hide Line numbers
1: = Sun’s current internal Standard ARC Review Process
2: 
3: ||**Table of Contents**
4: |
5: * [[Background>>#INFO]]
6: * [[A Proposal Is Submitted and a Case Number Is Assigned>>#1]]
7: * [[The Project Is Assigned to an ARC>>#2]]
8: * [[A Case Owner Is Selected and a Case Directory Is Setup>>#3]]
9: * [[Required Materials Are Submitted and An Inception Review Is Requested>>#4]]
10: * [[An Inception Review Is Scheduled>>#5]]
11: * [[The Project Is Presented in the Inception Review>>#6]]
12: * [[Required Materials Are Submitted and A Commitment Review Is Requested>>#7]]
13: * [[A Commitment Review Is Scheduled>>#8]]
14: * [[The Project Is Presented in the Commitment Review>>#9]]
15: * [[An Opinion Is Drafted>>#10]]
16: * [[Feedback Is Solicited on the Draft Opinion>>#11]]
17: * [[The Final Opinion Is Published and the Case Is Closed>>#12]]
18: | |
19: ----
20: |
21:  This is a high-level description of Sun’s "Full ARC review" process.
22:  Two different ARC reviews are mentioned in the steps below - inception and commitment. They are illustrative of a "typical" review cycle, but other sequences of meetings can also be used. Both of these ARC reviews are typically performed for each project via the standard ARC review process, i.e.:
23: 1. An inception review is typically performed while a project is still in its formative stage. The purpose of an inception review is to give the ARC a basic understanding of what the project is and why it is being done, and this type of review also provides an opportunity for the project team to get ideas/feedback from the ARC about unsettled design issues, to gain an understanding of other projects that are similar and what will be expected for the case to be approved during the commitment review, etc. While an inception review (as outlined in steps 4 to 6 below) is not required for a project, it is highly recommended in order to avoid possible //gotchas// later in the review process.
24: 1. A commitment review is normally performed when the design aspect of a project is nearly complete (and no major changes in design are expected). A commitment review is required, i.e., once the ARC approves a project at commitment time, no significant architectural changes can be made unless the project is routed through the review process again, and, if a project is rejected by the ARC at commitment time, deployment is delayed until the project is successfully rerouted through the process or an //executive override// from SAC is obtained.
25:  The review-process steps below are divided into those that are
26: * *instigated by the submitter*  (or someone else on the project team)
27:  and those that are
28: * ^taken by the ARC^  as a response.
29: 1. *A Proposal (One-Pager) Is Submitted and a Case Number Is Assigned for a Project*
30:  A member of a project team uses the [[one-pager template>>Community Group arc.onepager]] to draft a short project description and then sends that one-pager (in text format with no more than 80 characters per line) to [an alias at Sun]. A case number, e.g., 2001/199, is assigned automatically upon receipt of the one-pager to identify the project throughout the review process, and the submitter is then informed via an automatic email of the case number. (For historical reasons, a project ID, formed from the date of submission and the full name of the submitter, e.g., 010628_john.doe, is also assigned to each one-pager.)
31: **Note:** Often, a number of different projects are related to one another as part of a product/offering. In such cases, a description of the overall product is submitted first, as a one-pager. This one-pager is known as the //umbrella// case. The overall product (i.e., the umbrella case) is then subjected to an inception review only, at which point, the ARC assists with decomposition into projects. Each project is then submitted separately for review via either the standard or the fast-track process.
32: 1. ^The Project Is Assigned to an ARC by the ARC Chairs and a Case Directory Is Setup^
33:  New one-pagers are immediately (and automatically) queued for ARC assignment by the SAC Advocates. Each week, the ARC Chairs (as members of the SAC Advocates) review the projects in the queue, assigning each to the appropriate ARC, e.g., services-related projects are assigned to the SARC, storage-related projects are assigned to the SHARC, etc. The submitter for each newly-assigned project is then informed of the ARC to which his or her project is assigned via email from a SAC Coordinator. Said email also includes specific instructions for scheduling reviews via the assigned ARC.
34:  A case directory for each newly-assigned project is created shortly after a case is assigned to a specific ARC, and the case directory is configured to hold project-related information, e.g., submitted materials, related email, contact names, regularly-updated status information, etc.
35: **Note:** Once the case directory for a project is configured, the submitter (or anyone on the project team) may send general communications to the ARC by placing the case number in the subject line of an email sent to the general alias for the ARC. (Such email is automatically archived in the case directory.)
36: 1. ^A Case Owner Is Selected for the Project^
37:  In the next meeting of an ARC after a project is assigned to it (or sometimes even sooner), an ARC member is selected to be the case owner (or shepherd) for the project, i.e., to help the submitter and/or project team prepare for review, etc., and an ARC intern may also be selected to assist the case owner. An email is sent by a SAC Coordinator to inform the project team about the case ownership, and prior to the following ARC meeting, the case owner or intern typically reviews the one-pager for the project and contacts the submitter directly to discuss the project and the ARC process, etc.
38: 1. *Required Materials Are Submitted and An Inception Review Is Requested for the Project*
39:  A submitter and/or project-team members prepare for an inception review by compiling required materials and by then submitting these materials to the ARC materials alias so that they can be placed in the appropriate area under the case directory by a SAC Coordinator. (The case number for the project must be in the subject line of the email, and the body of the email must indicate that the attached materials are intended for an upcoming //inception// review.)
40:  Before submitting materials, the submitter is responsible for meeting with the case owner or intern to ensure that the materials meet the ARC’s standards, to ensure that no important materials are missing, etc. Materials typically required for an inception review are:
41: 1* Presentation slides, including block diagrams, etc. that graphically depict the architecture of the project at a high level, etc.
42: 1* A completed ARC Questionnaire (in text format with no more than 80 characters per line). The different ARCs have different questionnaires. (It is acceptable to skip questions in the questionnaire that are not yet answerable at this stage of the project.)
43: 1* A list of interfaces imported and exported by this project.
44: 1* A list of any other projects on which this project depends.
45: 1* Specifications (such as man pages, header files, a functional specification, etc.).
46:  After sending the required materials for an inception review, the submitter (or any project-team member) requests an inception review by placing the case number for the project in the subject line of an email sent to the ARC agenda alias. (The body of the email must indicate that an //inception// review is being requested, and the body must also include any scheduling issues of the project team, i.e., upcoming weeks when necessary project-team members are not be available to attend the regular ARC meeting for the requested review, etc.)
47: **Note:** While most of the ARCs, at this point, do not schedule reviews until all required materials have been submitted, there are still a couple of ARCs that will schedule reviews prior to receipt of the review materials. Most notably, PSARC schedules reviews in that fashion. Since PSARC reviews are typically booked weeks to months in advance, each PSARC submitter is strongly encouraged to request reviews as soon as possible after his or her project is assigned.
48: 1. ^An Inception Review Is Scheduled for the Project^
49:  When a request for an inception review for a project is received by an ARC, a SAC Coordinator schedules the inception review in a slot on the agenda for an upcoming ARC meeting (giving the ARC members sufficient time to review the associated materials), and the submitter is apprised of the date, time, and location of the review via email.
50: 1. *The Project Is Presented in the Inception Review*
51:  A case owner or intern typically prepares an issues file containing any questions, comments, and issues that need to be addressed in an inception review prior to that review. A submitter and/or project-team members are usually allotted some time in the inception review to present the high-level architecture of the project. The remaining time is then reserved for ARC members to ask questions (some of which may be sent to the submitter in advance of the meeting), to answer any questions about the case and/or the review process, to provide advice about unsettled design issues, other projects that are similar, etc., and to, in general, prepare the project team for what will be expected in the future commitment review.
52: **Note:** Each ARC review is recorded and archived on the SAC server. In addition, minutes are taken at each ARC meeting and are later posted to the intranet by a SAC Coordinator.
53: 1. *Required Materials Are Submitted and A Commitment Review Is Requested for the Project*
54:  A submitter and/or project-team members prepare for a commitment review by compiling required materials and by then submitting these materials to the ARC materials alias, so that they can be placed in the appropriate area under the case directory by a SAC Coordinator. (The case number for the project must be in the subject line of the email, and the body of the email must indicate that the attached materials are intended for an upcoming //commitment// review.)
55:  Before submitting materials, the submitter is responsible for meeting with the case owner or intern to ensure that the materials meet the ARC’s standards, to ensure that no important materials are missing, etc. Materials typically required for a commitment review are:
56: 1* Presentation slides, including block diagrams, etc. that graphically depict the architecture of the project at a high level, etc.
57: 1* A completed ARC Questionnaire (in text format with no more than 80 characters per line). The different ARCs have different questionnaires.
58: 1* A list of interfaces imported and exported by this project.
59: 1* A list of any other projects on which this project depends.
60: 1* Specifications (such as man pages, header files, a functional specification, etc.).
61: 1* Responses to any unresolved issues raised during the inception review.
62:  After sending the required materials for a commitment review, the submitter (or any project-team member) requests a commitment review by placing the case number for the project in the subject line of an email sent to the ARC agenda alias. (The body of the email must indicate that a //commitment// review is being requested, and the body must also include any scheduling issues of the project team, i.e., upcoming weeks when necessary project-team members are not be available to attend the regular ARC meeting for the requested review, etc.)
63: 1. ^A Commitment Review Is Scheduled for the Project^
64:  When a request for a commitment review for a project is received by an ARC, a SAC Coordinator schedules the commitment review in a slot on the agenda for an upcoming ARC meeting (giving the ARC members sufficient time to review the associated materials), and the submitter is apprised of the date, time, and location of the review via email.
65: 1. *The Project Is Presented in the Commitment Review*
66:  A case owner or intern usually updates the issues file for a project to contain any questions, comments, and issues that need to be addressed in a commitment review before the review is held. Commitment reviews may be handled in slightly different fashions among the ARCs; however, one thing is consistent among all ARCs. That is, after case discussion is complete and the ARC members have raised their issues and their advised and required technical changes (TCAs and TCRs), a vote is taken to decide the disposition of the case. Based on the majority opinion of the ARC (with the ARC Chair breaking any tie), the project is then approved unconditionally, approved with TCAs and/or TCRs, or rejected.
67: **Note:** Outright rejection of cases is very rare. Typically, projects are approved with TCAs and/or TCRs.
68: 1. ^An Opinion Is Drafted for the Project^
69:  Typically within fourteen days of the commitment review for a project, the case owner or intern uses an [[opinion template>>Community Group arc.opinion]] to create an opinion for the case in the case directory for the project. The opinion is intended to document the outcome of the commitment review, i.e.:
70: 1* the ARC’s decisions and reasoning.
71: 1* the project’s architecture.
72: 1* the //interfaces// that the project offers (imports) or depends on (exports) and the specification and stability classification (aka //commitment level//) for each interface.
73: **Note:** In addition to the opinion content mentioned above, an opinion might also provide advice to the project, its product approval committee, or other readers (such as other project teams that depend on the case), and, if a project is rejected by the ARC, the opinion must explain why and must describe the changes required to seek reapplication.
74: 1. ^Feedback Is Solicited on the Draft Opinion for the Project^
75:  After an ARC opinion is drafted (but still typically within fourteen days of the associated commitment review), the case owner distributes it to the ARC and the project team (via an email message that includes the case number for the project in the subject line), requesting feedback about the opinion within, usually, seven additional days. The ARC and the project team ensure that the opinion accurately describes the project, the discussion, and the decisions made.
76:  Seven days (or thereabouts) after distributing the original draft opinion, i.e., after the case owner or intern incorporates feedback from the ARC and the project team to ensure that the opinion accurately reflects the case, commitment-review decisions, etc., the case owner solicits additional feedback about the possibly-revised opinion from the members of all ARCs via an email sent to the opinion-feedback alias for all ARCs, requesting feedback about the opinion within, normally, another seven days.
77: **Note:** The second round of soliciting feedback improves consistency of ARC decisions and opinions. The broader experience of the members from other ARCs also increases the likelihood that inter-project relationships will be identified. On very rare occasions, this second round results in a case remaining open for further review by the SAC Advocates, the current ARC, or another ARC, instead of the case being closed, etc., as outlined in the following step.
78: 1. ^The Final Opinion Is Published for the Project and the Case Is Closed^
79:  After a week or so of review by all of the ARCs, the case owner announces the possibly-revised, now-final opinion to the project team and initiates formal archiving and publishing of the final opinion via an email sent to the SAC opinion alias.
80:  Upon receipt of the above-described email from a case owner, a SAC Coordinator archives and publishes the opinion. Additionally, just prior to or just after sending the above-described email, the case owner officially closes the case by updating its status (in the case directory) appropriately, i.e., with a closure status of either approved or denied, based on the outcome of the commitment review.
81: **Note:** Once an ARC opinion is final, the opinion is binding on the project, i.e., for a rejected case, the project team must make the required changes prior to seeking reapplication, and, for an approved case, the project team must implement any and all TCRs, give ample consideration to any and all TCAs, make no significant changes without rerouting the project through the review process (possibly via a fast track), etc. If a project team considers the final ARC opinion to be erroneous, the team may follow the appeal process (to request that the case be reopened for further review by the SAC Advocates, etc.), or the team may request an //executive override// from the SAC itself.
82: |
OpenSolaris

Top Menu

Wiki code for Reference: Sun's current internal ARC process

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group arc Pages
