Multics Technical Bulletin MTB-650
MCRB Reorganization
To: Distribution
From: P. Benjamin, C. Jones, M. Kubicar, M. Pierret
Date: 02/28/84
Subject: Proposal to Reorganize the MCR Board
1 PURPOSE
The Phoenix and Cambridge Multics Change Request Boards
appointed a committee of four people to investigate problems with
the MCR process and suggest ways in which the problems can be
solved. The four members of the committee, Paul Benjamin, Chris
Jones, Mike Kubicar and Matt Pierret, met via forum to attempt to
isolate the causes of the problems experienced by the MCR boards.
Problems were separated into two classes, those stemming from the
way in which the boards met (meeting procedures) and those
stemming from fundamental issues in the Multics development
cycle. This task report describes the problems discussed by the
committee and recommendations for solutions to the former class
of problems. Thoughts on the latter class of problems are also
included, but no concrete recommendations are made at this time.
Comments should be sent to the author:
via Forum:
>udd>m>mcrs>MCR_procedures.
via Multics Mail:
Pierret.Multics on either MIT Multics or System M.
via telephone:
(HVN) 261-9338 or (617) 492-9338
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
MTB-650 Multics Technical Bulletin
MCRB Reorganization
2 OVERVIEW OF THE PROBLEM
Concisely stated, the problems examined by the committee are
as follows:
1) Inter-board antagonism: It is clear to this committee that
the mere existence of two boards helps to create an
unproductive spirit of competitiveness and mutual mistrust.
Under such conditions it is too easy to lose sight of the
common objective and much time is wasted attempting to
anticipate the "other" board's reactions.
2) Personality clashes: Although personality clashes have
caused problems in the past, this committee believes this to
be a minor issue made overly visible by other problems, such
as having the two boards.
3) Too many board members: This committee believes that the
large number of people involved makes resovling differences
overly difficult. On the other hand, it is unwise to limit
the scope of peer review too much. A balance must be struck
between including as many as possible for peer review while
including as few as possible for efficiency in
decision-making.
4) Negligent board members: Board members are not always
adequately prepared, causing confusion and last minute
changes. Board members must be held responsible for being
prepared, and must be given the resources to do so.
5) Everyone is a command syntax expert: This problem is really
a symptom of other problems: inadequately prepared board
members and a lack of standards describing "correct" command
syntax.
6) Lack of standards: For most issues there is no clear
standard on which to rely. Developers and board members too
often find themselves in a gray area with little guidance.
The fact that the boards decided one way once does not mean
that the boards will decide the same on another occasion.
And often proponents of two different ways of doing
something can each make a good case saying that their way is
already an implied standard. A clearer set of standards
will go a long way to resolving disputes and helping
developers known the proper way to do things in the first
place.
7) Responsibility is not clearly assigned: It is too often
simply not clear who is responsible for getting what done
when. Is the developer to blame if the MCR she submits
Multics Technical Bulletin MTB-650
MCRB Reorganization
creates a lot of controversy? Is the MCR board to blame for
failing to resolve an MCR before the installation freeze?
Or is management at fault for not keeping on top of things?
The issue of responsibility is partially addressed in this
report.
8) The purpose of an MCR and its place in the development cycle
is unclear: Exactly when and why an MCR should be
submitted, what amount of review is necessary and the whole
development cycle is not entirely clear. Although solving
this problem is probably beyond the purview of this
committee, discussion of the problem is included.
3 OVERVIEW OF A RECOMMENDED SOLUTION
The changes recommended below, if approved by the current
MCR boards and management, are intended to be implemented on a
trial basis. During this experimental phase, lasting three
months, various details will be altered slightly until the new
process stabilizes. At that time an MAB will be written
officially describing the new procedures, including the
alterations made during the experimental phase. It is important
that whatever solution is agreed upon is given time to prove
itself.
This committee recommends that the MCR boards alter the
structure of the MCR boards and the manner in which MCR board
meetings are held. The recommendations described in the
following sections attempt to address those problems which stem
from the manner in which the current boards conduct business. It
does not address some larger, more fundamental problems.
The intent of the recommended solution is to:
1) restructure the boards and their meetings procedures in such
a way as to include a large portion of the Multics community
in the peer review process without reducing the efficiency
of the decision-making process, to unify the multiple
development sites as much as possible and to streamline the
process by which non-controversial MCRs are handled;
2) provide guidelines for MCR board members and MCR submitters;
3) assign responsibility for the functioning of the MCR
process.
4 STRUCTURE OF THE MCR BOARD
The Multics Change Request Board will be expanded to include
potentially all interested developers and documentation workers
MTB-650 Multics Technical Bulletin
MCRB Reorganization
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).
4.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 Calgary 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 (as
is) or recommends it be resolved by the EMCRB. The GMCRB
provides the initial peer review upon which controversial MCRs
are ultimately resolved. Because this board is not directly
involved in the resolution of such MCRs, the large membership is
not such a burden on the efficiency of the decision-making
process. At the same time, peer review by a large audience is
not sacrificed.
The GMCRB has one officer to act as the online chair.
Management, i.e, John Gintell and Paula Wood, appoint the GMCRB
chair. If for any reason the GMCRB chair will not be able to
perform her duties, she appoints an acting chair, or, failing
that, management appoints an acting chair.
4.2 The executive board
Membership of the Executive MCR Board (EMCRB) is open to a
small number of individuals appointed by management. The EMCRB
is a single board which resolves all MCRs that could not be
resolved by the GMCRB. The EMCRB is small (to make MCR
resolution more efficient) and is a single unit (to prevent the
problems of competing boards). The EMCRB is to consist of six
(6) members, with three (3) from each of the Phoenix and
Cambridge development organizations.
It will be the responsibility of management to determine the
representation from their organizations. It is suggested that
management choose those individuals in a manner that will ensure
that the major aspects of Multics software development are
adequately represented. It will be the responsibility of the
Multics Technical Bulletin MTB-650
MCRB Reorganization
board members to be fully prepared to discuss the merits of the
MCRs under consideration. It will be the responsibility of
management to ensure that the members they appoint have enough
time to do that.
The EMCRB has two officers to act as chair and secretary,
respectively.
5 MEETING PROCEDURES
5.1 MCR_Board Forum meeting
The GMCRB reviews packets of MCRs via the MCR_Board Forum
meeting. This meeting is a replacement for the MCR_Discussion
meeting. The second transaction in the MCR_Board meeting will
contain a description of conventions to be followed, such as
proper format for subjects and the conventions described below.
This will make it harder for someone to overlook the description
of new conventions, so ignorance of the law will be no excuse.
Packets are generated on Tuesdays, in the same manner as
they are generated today, and a packet generated on Tuesday of
fiscal week N is open to discussion until Noon, Central Standard
Time, 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.
5.2 Selection of MCRs in need of resolution
At Monday Noon (CST) the discussion is gaveled closed. The
chairperson of the GMCRB 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 chairperson may include an amended version of the MCR on
the ballot rather than the original when it appears, in her
opinion, 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 chair not include
amendments which are major changes or re-designs of the original
MTB-650 Multics Technical Bulletin
MCRB Reorganization
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.". At any rate, there is to be
only one version of the MCR on the ballot, either the original or
the amended version.
On Tuesday, GMCRB members cast a "recommend referral" vote
for each MCR on the ballot to which the member objects and wishes
the EMCRB to resolve. GMCRB members may cast an "approval" vote
for each MCR on the ballot of which the member approves. If the
member has no objection to the MCR as described on the ballot,
and no particularly strong need to voice approval of the MCR, she
casts no vote. Each MCR which receives five (5) referral votes
is placed on the EMCRB's agenda. Those MCRs which were not on
the ballot and those MCRs which did not receive at least five (5)
referral votes are considered approved. Votes must be received
before 6:00 a.m. (CST) Thursday.
Balloting is done using the opinion_analysis software
written by Lindsey Spratt and a number of exec_com tools for
keeping track of MCRs. Information about the use of this
software and these tools can be found in the info files in
>udd>m>mcrb>info, starting with mcr_voting.gi.info. However, the
following is all that is strictly necessary to vote on MCRs:
1) Once per process issue the command:
ec >udd>m>mcrb>setup_to_vote
2) To find out the MCRs upon which votes may be cast, issue the
command:
list_proposals
3) To vote to have an MCR referred to the EMCRB for resolution
issue the command line:
ec refer_mcr NNNN
4) To vote to have an MCR approved (this is not strictly
necessary) issue the command line:
ec approve_mcr NNNN
See the info files for more advanced and flexible use of the
commands, such as including comments with votes and an alternate
command syntax. The GMCRB chairperson requires more advanced
(though not by much) knowledge of the opinion analysis commands,
including how to set up a proposals database and how make
proposals.
At some point in the future, after people have become
familiar with the voting software, it is a good idea to
investigate the possibility of having the GMCRB vote on more
things than just referral to the EMCRB, such as individual
amendments. At the present time, attempting to do so would
probably be difficult.
Multics Technical Bulletin MTB-650
MCRB Reorganization
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.
5.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.
Attendance is mandatory, i.e., an alternate must be supplied by
an EMCRB member who can not 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 contigent 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 her intention known as early as possible in
the MCR_Board meeting so that other members can be prepared to
discuss the MCR.
6 GUIDELINES
6.1 Assignment of responsibility
It seems clear that a contributing factor to the problems of
the current MCR process is that it is often hard to peg down just
who is responsible for making sure that poorly prepared, poorly
reviewed or excessively controversial MCRs are not submitted. It
also seems clear that the responsibility should be shared by the
EMCRB members and by management. 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 must be aware that she 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 review, 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.
MTB-650 Multics Technical Bulletin
MCRB Reorganization
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 should
allocate time for MCR resolution, perhaps on a worst case basis,
to attempt to avoid last minute problems.
MCRs will have, in additional to a "sponsor" field, a
"responsible manager" field. This will serve the dual purpose of
involving managers more in the MCRs their developers submit and
providing developers with the support that comes from knowing
that if things go wrong, they are not out on the limb alone.
EMCRB members also 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 will require 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.
6.2 Peer review
The review process currently used, or rather, intended to be
used by the Multics development organization is a sound one that
has been successful for many years. Of late, that process has
broken down because it has not been followed in earnest. It has
not been followed in earnest at least partly because there are no
clear documented guidelines defining the different types of
changes and the level of review appropriate for each type.
The documentation of such guidelines would require defining
the Multics development cycle. Such a task is outside the
purview of this committee, but an effort to define and document
such guidelines should be undertaken. Such guidelines would give
developers and managers a clearer picture of the reviewing
constraints that must be satisfied to avoid having the EMCRB
reject an MCR for lack of review and would give EMCRB members a
clearer picture of what can and should be rejected for lack of
review. Obviously, these guidelines must be relatively complete,
going beyond simple assertions (e.g., "An MTB describing the
change must be written and reviewed.") to include as much of what
is actually expected as possible (e.g., "An MTB describing the
change, including all user-visible aspects and a detailed
discussion of the implications, which is up-to-date with the
change to be installed, must be written and subjected to review
by the Multics community. Results of any said review must be
Multics Technical Bulletin MTB-650
MCRB Reorganization
incorporated into the MTB as a revision or by a new MTB which
completely replaces the old.").
6.3 Actions by the executive board
The EMCRB may:
1) Approve an MCR with a majority vote.
2) Reject an MCR with a majority vote.
3) Postpone an MCR, assigning a member the responsibility to
resolve the issues causing the postponement.
4) Allow an MCR to expire unresolved.
An MCR must be resolved within three (3) EMCRB meetings, i.e., an
MCR may be postponed no more than two (2) times. This is to
encourage a postponer to resolve the issues causing the
postponement as soon as possible and to avoid leaving an MCR
submitter hanging for an indefinite period awaiting action by the
EMCRB. After three (3) meetings, if the MCR is not approved,
rejected or withdrawn, it expires unresolved. Expiration differs
from rejection in that an MCR should only be rejected if it
proposes a bad idea or the MCR was very poorly prepared. The
author may re-submit the MCR as another MCR after resolving the
complaints of the GMCRB and EMCRB.
The EMCRB must clearly spell out the reasons for rejecting
an MCR or for allowing an MCR to expire unresolved.
6.4 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
chairperson. 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.
6.5 Setting standards
One of the problems the boards now face is a lack of clear
standards. Currently the boards implicitly set standards, but
there is no documentation of these implicit standards and they
MTB-650 Multics Technical Bulletin
MCRB Reorganization
are not necessarily universally accepted. Many conflicts can be
resolved/avoided by simply having the EMCRB explicitly set
standards and document these standards.
Whenever an MCR is approved, even if the EMCRB did not
directly act on it (i.e., the MCR was not referred to the EMCRB)
which includes some new convention the EMCRB must decide if this
new convention should be accepted as a new standard. The EMCRB
secretary articulates the proposed new standard (e.g., "It
appears we are setting a new standard which says 'All control
arguments which enable an action should have a complimentary
control argument which disables that action.' Agreed?"), and the
EMCRB votes on whether this should be accepted as a new standard.
A new field will be added to mcr.lister,
standard_established, which will contain a description of any new
standards established as a result of the approval of the MCR.
Such new standards will later be incorporated in the Standards
SDN.