ARC Process Proposal

In the spirit of "thinking out loud and in public", the following is a proposal for putting the draft governance proposal into action.

See the  CAB Governance Proposal for background.

Assumptions

The specifics of these OpenSolaris architectural development processes will change many times as we gain experience with what works and what doesn't. This is expected and OK.

There exists a  metaprocess for changing the OpenSolaris development process that allows the above to happen. This proposal and its discussion is intended to trigger that metaprocess.

Gaps and Open Issues

1. Open Issue: The role of Architectural review is unclear in the CAB Governance document.
   The  CAB Governance Proposal includes the phrases
    "Communities that are dependent on a standardized or shared interface governed by an architecture board (ARC) must maintain a presence within that ARC."
    and
    "ARC decisions are therefore binding on the interfaces that they govern."
    This seems to imply a couple of misconceptions:
   1* that the ARC is somehow disjoint from the community, and
   1* that there are interfaces that the ARC does not govern.
    A better view is that the ARC is an extension of the community, giving the community a broader experience base in areas where it is needed, such as when dealing with architectural changes that affect other communities. In such a view, the Architecture of a system is a _shared_commons_ that everyone is expected to take care of. As I try to show in later posts, it is possible to manage the architecture of a system in ways that allows decisions to be safely delegated to smaller groups, such that "the entire ARC" does not need to be involved in everything; this does not mean that those decisions don't affect the shared architectural commons.

Glossary:

 The word "project" is used here to describe the task of identifying a need for a code change, planning how to make the change, getting the change approved, designing and implementing the change and finally, integrating it all back into the OpenSolaris source base. It may be prudent to use a different term, such as "change set" to avoid confusion with other meanings of the word (such as project="a source tree", project="a community" or project="some artifact in a community")

High level process "design pattern"

  An idea solidifies into a formal proposal which gets approved, after which development happens; when complete, a request is made to integrate the change into the common source base; when approved, the change is integrated.

Details

1. Every proposed change needs to be formally articulated in a bug report.

Intent
:

  In any project management, the clarity of the specification is of paramount importance - in group work it is exponentially so.  Groups that Work, by Gerard M Blair

 The desire here is to capture the intent of the change, not the design or implementation details. "We intend to redesign the entire virtual memory system...", "I intend to stop tar(1m) from core dumping when...", or "Here is how to add support for ksh88 to ksh93...".

Process
:
 Some part of the community comes up with an idea, discusses it and prototypes it, etc.
 When it's "ready" (whatever that means), someone writes a proposal that the community can evaluate.
 An evaluated bug report can meet this requirement, though the level of detail expected varies along with its complexity and risk.

1. The community needs to decide whether it wants the project.

Intent

 Code changes are tactical; evolution of a community's source base is strategic. The direction of that evolution needs to be by intent and not reactive. That is, it is better to say "we want to make a big change, and here is what we need to address to make it go smoothly" than to be forced into "we released a new version and found a whole slew of things that broke; now we have to scramble to fix them".

Process

For most projects, the default answer is expected to be "yes".  Reasons for "no" (or "not now") might be related to complexity, timing or the the "quality" of the proposal.
 The proposed "Lazy Approval (no -1's) and/or Lazy Consensus (three or more +1's and no -1's)" works well here. A "-1" vote serves to derail a proposal, either to kill it or to cause it to follow some other processes that deal with "more complicated" proposals.
 The result of this decision should be reflected in the bug report itself:
1* The priority of the bug reflects the community's desire.
1* The "closed, will not fix" and "closed, not a bug" states can indicate that the community does not want this bug fixed at all or does not consider it a bug in the first place.
1* Issue: How can this discussion be linked to the bug report?
1* Issue: Can the bug reporting system deal with "not now"?

1. The Project Lead needs to determine who should review the proposal, based on its architectural impact.

Intent

The set of reviewers needed is determined by the scope of the change. Sun has historically triaged this into three buckets:

1. 1. Projects with no architectural impact should be reviewed and self-approved by the project team itself (Details),
   2. Projects with common or obvious architectural changes should be easy to review by those affected (Details), and
   3. Complicated architectural changes need review and approval involvement from the other communities that will be impacted by the change. This last bucket is where cross-project and cross-component systems engineering concerns are raised and addressed. It is also the one that is most often associated with ARCs. (Details),  This approved architecture forms the basis for the design and implementation that follows.
2. The project team develops the code change.

Intent

Once the project gets the two approvals above, they need to design, implement and test it. The specifics of how this happens (waterfall -vs- agile -vs- ...) are left to the community to determine as they see fit.
 When the development is done, the project is ready to request integration. Approval for integration is based on several things, including whether or not the project actually delivered something that followed the architectural spec that was approved. The community is free to add whatever other constraints it wishes as well.

1. The project team integrates the result.
    At this point,  before we have a SCM solution in place, there is a mechanism to request a sponsor who will do the actual integration work for you if you are not a Sun employee. See the Sponsorship process for more info.
    Work on the SCM topic is beyond the scope of this proposal.