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.