MULTICS ADMINISTRATIVE BULLETIN MAB-048-02
| To: | MAB Distribution |
| From: | Ron Barstad |
| Date: | August 12, 1985 |
| Subject: | Rules for the Multics Change Review Board |
ABSTRACT
This Multics Administrative Bulletin defines the structure of the Multics Change Review Board (MCRB) and the procedures that the board, and others doing business with the board, are to follow in the course of processing Multics Change Requests (MCRs).
RELATED DOCUMENTS
This MAB is one of a set dealing with Multics Configuration Management. For an overview of this set see MAB-070 "Multics Configuration Management: Policy Statement".
The following MABs discuss related topics and should be consulted. Any reference to MCR procedures in these documents is amended by this MAB.
- MAB-006 Design Reviews (74-01-02)
- MAB-023 Multics Software Changes (75-04-02)
- MAB-002 New Procedures for Changes to Multics (73-08-22)
- MAB-017 New Multics Change Request Form (74-10-21)
- MAB-018 Documentation to be Submitted with MCRs (74-12-05)
- MAB-019 Submission of Multics Change Requests (75-01-02)
- MAB-026 New Procedures for Change Review Board (75-09-18)
- MAB-031 Publication of Approved MCR's (76-06-06)
- MAB-051-05 Phoenix Multics Change Review Board (82-09-02)
1 INTRODUCTION
This document has been rewritten to describe the procedures and policies of the Multics Change Review Board (MCRB). The purpose of the MCRB is to include the Multics development community in the peer review process without reducing the efficiency of the decision-making process.
This document provides guidelines for MCR board members and MCR submitters and assigns responsibility for the functioning of the MCR process.
1.1 Definition of MCR
A Multics Change Request (MCR) is a formal request for permission to install a change to Multics. The request should come late enough in the development cycle so that the implications of the change that are subtle enough to be easily missed in the earlier design phase have a chance to be aired. The Multics Change Review Board functions as a peer review process by judging MCRs on their technical merits only. An MCR is not the vehicle for obtaining permission to do the work. Permission to do the work and other resource allocation tasks are management responsibilities and not part of the peer review process.
1.2 Multics Organizations
The following Multics development organizations are directly involved in the MCRB process.
-
Multics Development Center (MDC), consisting of
- Cambridge Information Systems Laboratory (CISL)
- Phoenix Multics Development Center (PMDC)
- Advanced Computing Technology Centre (ACTC), at the University of Calgary, Calgary, Alberta, Canada
2 STRUCTURE OF THE MCR BOARD
The Multics Change Review Board potentially includes all interested developers and documentation contributors from all Multics development sites in a limited capacity, with a small subset of this membership empowered to resolve controversial MCRs. The larger membership is called the Greater MCR Board (GMCRB) and the subset is called the Executive MCR Board (EMCRB).
2.1 The Greater MCR Board
Membership of the Greater MCR Board (GMCRB) is open to all members of the development and documentation groups in MDC, and to development groups at ACTC and MIT. Members of other organizations which are involved in Multics development may become members of the board with the approval of the EMCRB (and of the Director of MDC if such individuals are not HIS employees). Those who do not require explicit approval become members simply by participating in the business of the GMCRB.
The GMCRB reviews all MCRs and either approves an MCR or recommends that it be resolved by the EMCRB. The GMCRB provides the initial peer review upon which controversial MCRs are ultimately resolved.
The GMCRB has one officer to act as the chairman of the MCRB forum meeting. This officer is appointed by the Managers of PMDC and CISL. If for any reason the GMCRB chairman will not be able to perform the required duties, an acting chairman will be appointed. The appointment is made by the chairman, or if that is not possible, by the chairman's Manager.
2.2 The Executive Board
The EMCRB consists of six members, with three each from PMDC and CISL. Members of the EMCRB are appointed by the CISL and PMDC Managers in a manner that will ensure that the major aspects of Multics software development are adequately represented. Board members must be fully prepared to discuss the merits of the MCRs under consideration. EMCRB members serve for a term of six months and may be reappointed.
The EMCRB has two officers, chairman and secretary, who are chosen by the board members.
2.2.1 DUTIES OF THE EMCRB CHARIRMAN
The EMCRB chairman has the following specific duties in addition to those as a regular EMCRB member.
- initiate the weekly EMCRB teleconference
- preside over the EMCRB meeting
- chair the EMCRB forum meeting
2.2.2 DUTIES OF THE EMCRB SECRETARY
The EMCRB secretary has these additional specific duties.
- record business of weekly EMCRB meeting and publish minutes
- prepare the MCR packets
- maintain the MCRB online hierarchy
- distribute resolved MCRs to submitters and involved others
3 ONLINE HIERARCHY
Much of the business of the MCR Boards is conducted on System M. Some of the procedures are done automatically via various tools and some business is carried on by participation in forum meetings. The details of these day-to-day operations are not included here. For this information MCRB members should consult the info segments in the info directory described below.
The MCRB hierarchy on System M contains the following directories in the >udd>Multics>mcrb directory.
| Directory | Contents |
| execution | GMCRB member tools for voting, etc |
| info | help segs for these tools |
| source | source for these tools |
| packets | contains MCR packets |
| mailbox | mailboxes for submitting MCRs |
| meetings | MCRB forum meetings |
| minutes | EMCRB meeting minutes archives |
| admin | administrative tools for EMCRB secretary and GMCRB chairman |
| database | MCR lister and voting databases |
3.1 MCRB Forum Meetings
The forums in the meetings directory and their purpose are
- EMCRB (emcrb)
- This meeting exists to allow members of the Executive Multics Change Review Board (EMCRB) to carry on discussions of any EMCRB business which is appropriately done online. GMCRB members have read-only access.
- MCR_Board (mcrb)
- This meeting exists to allow members of the General Multics Change Review Board (GMCRB) to discuss MCRs and to propose amendments to them. See the transaction chain beginning with transaction [0002] of this meeting for the rules of this meeting (the last transaction in that chain contains the latest rules).
- MCR_Packet (mcr)
- This meeting contains all MCRs, one per transaction, beginning with MCR 6765. Those individuals who are eligible for GMCRB participation are read-only participants.
- MCR_Procedures (mcrp)
- This meeting discusses administration of the MCR process. Participation is open to GMCRB members.
4 MEETING PROCEDURES
4.1 MCR_Board Forum Meeting
The GMCRB comments on packets of MCRs via the MCR_Board Forum meeting. The chain starting with the second transaction in the MCR_Board meeting contains a description of conventions to be followed, such as proper format for subjects and the conventions described below.
Packets of MCRs are generated on Tuesdays. A packet generated on Tuesday of fiscal week N is open to discussion until Noon, Central Standard Time (CST), on Monday of fiscal week N+2. Comments entered before that time are used to determine those MCRs in need of further action. Discussion can continue on MCRs in packet N, but if no objections to an MCR are raised by the deadline that MCR will be considered approved.
During the discussion period GMCRB members can raise questions, propose amendments, voice concerns and comment in any responsible way.
4.2 Selection of MCRs in Need of Resolution
At Noon (CST) the discussion is gaveled closed by the GMCRB chairman. The chairman examines the week's proceedings and prepares a ballot of all MCRs in the packet which received negative comments, about which questions were asked but answers were not received or about which amendments were proposed. The GMCRB chairman may include an amended version of the MCR on the ballot rather than the original when, in the chairman's opinion, it appears that the MCR as written will fail. This is to allow for the case where it seems clear that everyone supports an amendment, especially if the author of the MCR made the amendment. It is important that the GMCRB chairman not include amendments which are major changes or re-designs of the original MCR. Amendments made at this point should be simple, relatively minor and clear-cut, e.g., "Add -no_bar to complement the proposed -bar control argument.". Every amended MCR will appear on the ballot.
On Tuesday, GMCRB members cast a vote for each MCR on the ballot. For each MCR, members may either:
- vote to approve
- vote to refer
- abstain by not voting at all
The info segments in the >udd>Multics>mcrb hierarchy should be consulted for the actual mechanisms for review of and voting on MCRs.
Once voting is completed, the MCRs in the packet are officially resolved with respect to the GMCRB. Each is either approved or is in the hands of the EMCRB.
4.3 Executive Board Meeting
The EMCRB meets at noon (CST) [11:00 a.m. (MST), 1:00 p.m. (EST), 2:00 p.m. (EDT)] every Thursday via teleconference when there are MCRs for its consideration. Attendance is mandatory, i.e., an alternate must be assigned by an EMCRB member who cannot attend or one will be appointed by the members present. Voting is based on a majority of the membership.
The EMCRB will consider those MCRs which both raised controversy in the GMCRB and had a reasonable contingent who thought that it should be acted on by the EMCRB, and those MCRs that an EMCRB member petitions to have included in the agenda. In the latter case the EMCRB member must have a good reason, such as late-breaking news or managerial mandate. The petitioning member should make this intention known as early as possible in the MCR_Board meeting so that other members can be prepared to discuss the MCR.
4.4 Actions by the Executive Board
The EMCRB may:
- Approve an MCR with a majority vote.
- Reject an MCR with a majority vote.
- Postpone an MCR, assigning a member the responsibility to resolve the issues causing the postponement.
- Allow an MCR to expire unresolved.
The EMCRB must clearly spell out the reasons for rejecting an MCR or for allowing an MCR to expire unresolved.
4.5 Amending an MCR
The amendment process does not exist so that major changes can be made to an MCR or so that it can be redesigned by either board. Amendments that significantly change the intent or effect of an MCR are not appropriate and should be ruled so by the EMCRB or GMCRB chairman. Similarly, amendments of a less significant nature should be viewed with concern by the board if a reasonably large volume of such amendments are applied to an MCR, and it is a reasonable and appropriate action for an EMCRB member to vote to reject such an MCR on the grounds that it is symptomatic of a change that is not well thought out and should be resubmitted in an amended form.
5 GENERAL GUIDELINES
It is important that poorly prepared, poorly reviewed or excessively controversial MCRs are not submitted. The EMCRB must be firm in its commitment to reject any poorly prepared or poorly reviewed MCR no matter what the circumstances or the implications. The sponsor is responsible for more than a cursory glance at the MCR, and is as much to blame for allowing a "bad" MCR to be submitted as the author. At the same time, the EMCRB must respect the outcomes of prior reviews, if consensus was reached on all aspects of the change and if all Multics developers had a fair opportunity to participate in the review(s).
Management, as the allocator of resources, must be cognizant of the fact that the amount of resources spent on a change will not be considered in the deliberations of the GMCRB and EMCRB. Management must be responsible for making sure that developers know and understand the procedures for making a change and for making sure that changes for which they are responsible actually do receive the necessary review early enough to prevent problems. During the planning stages of any project, management must allocate time for MCR resolution, perhaps on a worst case basis, to attempt to avoid last minute problems.
EMCRB members have a responsibility to prepare themselves adequately so as to be able to make informed decisions and to resolve as many problematic issues before the EMCRB meets. This requires a significant commitment of time on each EMCRB member's part. It is important that the time necessary to be a responsible EMCRB member be factored into the member's overall schedule and that the member's manager is willing to allocate that time.
Appendix A - MCR Form
The MCR form on the next page is similar to one that would be generated with the Emacs mcr-mode in the >udd>m>mcrb>e directory. This is the recommended method of constructing a MCR. The mcr-mode is the final authority on the content and form of the MCR. The Emacs mcr-mode will automatically fill in some of the fields (author and date, for example) and will truncate some fields that are not checked as applicable. Typing a "?" for any field will cause an explanation of that field to be displayed.
_________________________________________________________________________ | Ver. 8 | | | 08/13/85 MULTICS CHANGE REQUEST | MCR______________ | |___________________________________________________|_____________________| | TITLE: | | | | AUTHOR: | | SPONSOR: MANAGER: | |_________________________________________________________________________| | CHARACTERISTICS | STATUS DATE | | Fixes Error Number(s): | Written: | | PFS Item for Release: | Status: | | Targeted for Release: |_____________________| | Documented in MTB: | CATEGORY (check >=1)| | Replaces MCR: |( )Lib. Maint. Tools | | Performance: ( )better ( )same ( )worse ( )new |( )Sys. Anal. Tools | | New Non-pl1 Programs: |( )Sys. Prog. Tools | | Incompatible Change: |( )Communications | | User Interface Change: |( )BOS | | Modification to TCB: |( )Ring Zero | |___________________________________________________|( )Ring One | | DOCUMENTATION CHANGES (specify one or more) |( )SysDaemon/Admin | | SRB Notice: |( )Languages | | Manuals: |( )Runtime | | MDD: |( )Std User Cmd/Subr | | Info Segs: |( )Unb User Cmd/Subr | | Other: | | |___________________________________________________|_____________________| SUMMARY: REASONS: IMPLICATIONS: TCB CHANGE IMPLICATIONS: SRB NOTICE: REASON FOR NON-PL/I PROGRAMS: DETAILED PROPOSAL: