;;; -*- Mode:Text; Fonts:(HL12) -*- 1 A Mechanism for Generating Technical Proposals* (David Saslav) 1Goals: * 1. To expedite the specification, design, implementation, and documentation of technical projects. 2. To assure that all projects are the product of a sound technical process, based to the greatest extent possible upon general consensus amongst the designers. 3. To provide an uncontroversial record of technical discussion, thus guarding against and helping to quickly rectify any technical miscommunication, misinterpretation, or misunderstanding which may occur. 4. To assure that input by each member of the technical staff is given fair, professional consideration. 1Mechanism:* This section describes the steps involved in generating, announcing, commenting upon, distributing, and voting upon proposals. 11. *WHEN TO WRITE A PROPOSAL The Proposal process is meant to serve as a means of fostering discussion and achieving consensus on controversial technical issues, and should be used only as a last resort for generating such consensus. Informal discussion amongst staff members should be the primary means of eliminating controversy. 2. HOW TO 1TYPE IN A PROPOSAL* OR 1RESPONSE TO A PROPOSAL* Proposals should be named with a slightly condensed version of the proposal 1Title*, and saved in the directory 1"JB:PROPOSALS;"*. The proposal format should be similar to that of this file, consisting of a 1Title* and 1Author*, centered on the first and third lines of the file. There should be sections for each Proposal's 1Technical Background*, its 1Purpose/Goals*, its 1Mechanism/Implementation*, any 1Comments*, and its1 Status*. The mechanism/implementation section should outline a general plan for accomplishing the purpose/goals of the proposal, and should be fully consistent with the technical background laid out in the 1Technical Background* section. The directory 1"JB:PROPOSALS.BACKGROUND;"* exists for those cases in which the technical background required for presenting a proposal is extensive enough to warrant separate containment. In this case, the proposal 1Author* should leave in the 1Technical Background* section a full pointer to the file in which the text resides. A template example of a recently-completed proposal may be found at the end of this file. If entering a response to an existing proposal, do so in the 1Comments* section at the end of the proposal file. Include the response date and your initials or name at the beginning of your response, and then write out a new version of the file. The last section of each proposal will be the 1Status* section. The original 1Status* of a Proposal is always "OPEN". For more details on Proposal 1Status*, see sections 15. Voting on a Distributed Proposal* and 16. Recording a Proposal's Status*. 1 *31. SEND A BRIEF ANNOUNCEMENT TO *THE DESIGN TEAM Once you have entered the initial proposal, send an announcement including the 1Title*, 1Author*, and a brief summary of the proposal to all relevant mailing lists. This alerts other technical designers to the existence of the proposal, and enables them to read and comment upon it. 1 *41. INTEGRAT*E1 TECHNICAL RESPONSE* 1INTO *THE 1PROPOSAL* After entering a comment to an existing proposal file, 2mail a complete copy* 2of all* added 2text to the* Proposal Author. At this point, it becomes the 1Author*'s responsibility to respond to the comment by mail, and also to update the Proposal to reflect the results of the ensuing discussion. The 1Responder*'s original comment text should be left intact, and a phrase inserted next to the commenter's name indicating the comment's disposition. 51. DISTRIBUT*E THE1 PROPOSAL *TO THE DESIGN TEAM The proposal, once submitted, will remain an active document. The 1Status* section will contain a phrase describing the current state of the idea under consideration. When a proposal's 1Author* believes that the proposal file contains sufficient information to serve as the basis of a decision, he may Distribute the Proposal. Distributing a Proposal consists of the following three steps, in order: A. Notating the proposal file's 1Status* section to read, "DISTRIBUTED"; B. Notating the entry in the file, 1"JB:PROPOSALS;TABLE-OF-CONTENTS.TEXT"* such that the 1Status* field for the proposal in question reads, "DISTRIBUTED"; C. Distributing a hardcopy of the entire proposal file to all members of the technical design staff on the day before a Proposal Meeting has been scheduled. 1Proposal Meetings* must be announced in writing by means of a ZMail message to the relevant mailing lists no later than 24 hours before the scheduled meeting time. 61. VOT*E1 ON* THE1 PROPOSAL* Each project member will have a chance to record his vote during the 1Proposal Meeting*. If a member is absent due to illness, his vote may be cast by proxy. A 2/3 consensus of the entire technical staff of GigaMos Cambridge constitutes a decisive 1Vote*. The calling of a 1Vote* is done by the Project Manager, unless he is also the Proposal's 1Author*, in which case, the 1Vote* will be called by the Company President. The possible results of a Proposal 1Vote* are: 1. Acceptance of the Proposal 2. Rejection of the Proposal 3. Deferment of the Proposal for further modification and a future voting A Proposal should be considered Deferred by default until a 2/3 consensus is attained either Accepting or Rejecting the Proposal at a Proposal 1Vote*. The Proposal Administrator is also responsible for electronically mailing an accounting of all 1Vote*s taken at 1Proposal* 1Meeting*s, within 24 hours after the 1Vote*. The official GigaMos work schedule will be updated to reflect this verdict unless, within 24 hours of having received the Proposal Administrator's notification of a given Vote's verdict, the president Overrules that verdict. See the next section for details on Overruling. 71. RECORDING A PROPOSAL'S STATUS* Proposals which have been Accepted or Rejected will be considered 2closed*; Proposals which are neither Accepted nor Rejected will remain 2open*. All proposals remaining open remain the responsibility of the 1Author*, until such time as sufficient new modifications exist to warrant another Proposal Distribution. Files containing Proposals which have been either Accepted or Rejected should have their 1Status* fields modified by the Project Manager to read "8CLOSED* -- [decision]" where [decision] summarizes the intent of the majority 1Vote*. Within 24 hours, the Company President may overrule a 2/3 majority 1Vote*, from "Accepted" to "Rejected", or from "Rejected" to "Accepted". To do this, a written explanation must be entered into the 1Status* field at the end of the Proposal file. See the sample proposal at the end for an example. 81. *STORING, FINDING, AND MOVING1 PROPOSALS* There is one relevant directory, with three relevant subdirectories: Directory "JB:PROPOSALS;" Subdirectory "JB:PROPOSALS.ACCEPTED" Subdirectory "JB:PROPOSALS.ARCHIVE" Subdirectory "JB:PROPOSALS.ACCEPTED" Subdirectory "JB:PROPOSALS.BACKGROUND" While being fleshed out, Proposals live at the top level of the directory "JB:PROPOSALS;" Proposals that have been Rejected are deleted from the top level directory and placed in the subdirectory1 "JB:*PROPOSALS.1ARCHIVE;"*. Proposals that have been Accepted are deleted from 1"JB:PROPOSALS;"* and placed in the subdirectory 1"JB:*PROPOSALS.1ACCEPTED;"* for further processing. Accepted Proposals become the input for a new process, the goal of which is to generate Project Specifications for imminent distribution. As discussed above, the subdirectory "JB:PROPOSALS.BACKGROUND" is to be used for extensive discussions of technical details used as background for a proposal's more formally action-oriented content. To assist in finding a given proposal, the Proposal Administrator will be responsible for maintaining the file, 1"JB:PROPOSALS;TABLE-OF-CONTENTS"*. This file will contain relevant information about each proposal [1Title*, 1Author*, Proposal Filename, 1Status*, and 1Last* 1Proposal* File1 Modifier*]. From the fictitious file 1"JB:PROPOSALS;END-ALL-WAR"*: ;;; -*- Mode:Text; Fonts:(HL12 HL12B HL12I) -*- 1Ending *Draft Last Revised 2/31/88 -- John Doe) 1Background:* See the file 1"JB:PROPOSALS.BACKGROUND;HISTORY-OF-WAR.TEXT"* for a detailed account of all wars throughout history. 1Goals:* To construct a mechanism which ensures that no war ever take place again. 1Mechanism:* 11. Kill all the lawyers*. : : : 1Comments:* -------- [Jane Doe 24-Oct-88:] "Kill all the lawyers" should come before step 7. In fact, it should be the first thing you do. [Proposal modified to reflect this. --J.D.] 1Status:* CLOSED, ACCEPTED BY 7-1 -- P. R. Oject-Manager ____________________________________________________________________ |DECISION OVERRULED: PROPOSAL REJECTED | | First of all,... | : | : | Secondly,... | : | : | On the other hand, | : | : I Last, but not least, I overruled this Proposal because I am a lawyer in my | spare time. | --C. O. Mpany-President ----------------------------------------------------------------------------