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


     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:                                                       

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


     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

  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

  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

  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

  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.


     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

     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


     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,


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

     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  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
  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

     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

     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.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

     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