;;; -*- Mode:Text; Fonts:(HL12 HL12B HL12I) -*- 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. TYPE IN A PROPOSAL/RESPONSE TO A PROPOSAL* Proposals should be mnemonically named (preferably with a slightly condensed version of the proposal 1Title*) and written to the directory 1"JB:PROPOSALS;"*. The proposal format should approximate that of this file, consisting of a 1Title* and 1Author* (centered on the first and third lines of the file, modulo the attribute line), as well as headered sections for the Proposal's 1Technical Background* (if able to be stated briefly), its 1Purpose/Goals*, its 1Mechanism/Implementation*, its 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 2. SEND A BRIEF ANNOUNCEMENT TO "INFO-FALCON"* Once you have entered the initial proposal, send an announcement including the 1Title*, 1Author*, and a brief summary of the proposal to the mailing list, 1"INFO-FALCON"*. This alerts other technical designers to the existence of the proposal, and enables them to read and comment upon it. 1 3. INTEGRATING TECHNICAL RESPONSE* 1INTO A PROPOSAL* When entering a comment to an existing proposal file, 2mail a complete copy* 2of all text you have added to the file*. This alerts the 1Author* (who should be receiving and reading mail sent to this mailing list as well) to the existence of a technical response requiring integration into the body of the proposal ("counter-response"). Whenever mail is received announcing response to one of an 1Author*'s existing proposals, that 1Author* then spends a few minutes addressing whatever points have been raised. This process could involve one or more of: careful reading of the text (either in ZMail or in the proposal file itself), one-on-one discussion with the 1Responder*, and a thoughtful re-evaluation of the relevant points. Once the 1Author* has decided upon an appropriate means of integrating the 1Responder*'s points, the 1Author* then modifies the existing proposal to reflect this particular modification. The 1Responder*'s original comment text (in the 1Comment* section of the Proposal) should be left intact, and a phrase inserted next to the 1Responder*'s name and date (found at the beginning of the particular response) indicating the action taken 2vis a vis* the comment. See the example at the end of this file for a sample Comments section. 14. Distributing a Proposal * 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 "INFO-FALCON" no later than 24 hours before the scheduled meeting time. [This rule is in effect until such time as an announcement is made to "INFO-FALCON" outlining a regular per-week meeting schedule; at that time, all meetings times will be considered to be planned by default in accordance with this schedule, and the Proposal Distribution deadline will be 24 hours before the (now implicitly) scheduled meeting. 15. Voting on a Distributed 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 Proposal Administrator (unless he is also the Proposal's 1Author*; in this case, the 1Vote* is called by the Project Manager). 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 official GigaMos work schedule will be updated to reflect this verdict unless, within 24 hours of the 1Vote*, the president Overrules the 1Vote*. See the next section for details on Overruling. 16. 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 (at the 1Author*'s discretion). 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 (2/3 or more majority) 1Vote*. Within 24 hours, the Company President may overrule a 2/3 majority 1Vote*. 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. 17. Migrating Proposals* Proposals that have been Rejected are deleted from 1"JB:PROPOSALS;"* and placed in the directory1 "JB:ARCHIVE;"*. Proposals that have been Accepted are deleted from 1"JB:PROPOSALS;"* and placed in the directory 1"JB:ACCEPTED;"* for further processing. Accepted Proposals (those in 1"JB:PROPOSALS;"*) become the input for a new process, under the joint purview of the Proposal Administrator and the Project Manager, the goal of which is to unify related proposals and to generate Project Specifications. 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*, 1Status*, and1 Last Proposal Modifier*]. The Proposal Administrator is also responsible for electronically mailing an accounting of all 1Vote*s taken at 1Proposal Meeting*s, within 24 hours after the 1Vote*. From the fictitious file 1"JB:PROPOSALS;END-ALL-WAR"*: ;;; -*- Mode:Text; Fonts:(HL12 HL12B HL12I) -*- 1Ending War* (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 -------------------------------------------------------------------------------------