------------------------------------------------------------------------------ -- draft -- -- draft -- -- draft -- -- draft -- A Formalized Proposal Review System for GigaMOS Systems Inc. Purposes: (1) To assure GigaMOS Systems makes the best possible major design decisions, given its resources and goals. (2) To assure technical staff members of GigaMOS systems fair consideration of any proposals they might make, including written response from Senior Project and Company Management. (3) To provide a written record of the company consideration on these issues. It is believed that this record will be valuable to the company in several ways. If the same or related issues come up in the future the value of a written record of previous deliberations is obvious. In addition, the written record provides considerable safeguards against "misspeakings", and, in the event of a misunderstanding, may enable the point to be clarified without taking the time of the entire set of persons involved in the decision making process. Furthermore, a written record may lead to more considered comments (i.e. inhibit FLAMING), may be more governed by technical realities as opposed to debating (shouting?) ability (or tolerance, etc) and may enable us to consider more complex aspects of matters than we could in a face to face discussion. Mechanism: -- this is a baseline for starters. Feel free to make suggestions. etc. Any technical staff member (or members) who have an idea for a major change, alteration, elaboration, or addition to the then existing official plans of GigaMOS Systems Inc. is encouraged to write them up and submit them in the form of an official proposal. These proposals as machine readable text in the directory JB:PROPOSALS;PROP-nn. Henry will be responsible for maintaining a table-of-contents file JB:PROPOSALS;TABLE-OF-CONTENTS which will give relavent information about each proposal [Title, proposal number, current status, date last modified, date company response last modified, etc]. The proposal, once submitted, will be considered an active document which reflects the current state of consideration of its issue; this avoids the need to read through a lengthy sequence of files or messages to "come up to speed" on the issue. The proposal should have sections considering its impact on schedules and resource requirements, but these could be dummies early in the proposal's lifetime. Thus, the proposal may be updated or elaborated by those making it and technical staff members are encouraged to make comments on the proposal, which should be appended to the end of proposal in a distinctive section, labelled with the name or initials of the person or persons making them. Normally, one should not edit another's section, except by making short bracketed and signed additions, although, if an idea from a suggestion is adopted into the main proposal it would be appropriate for the proposal makers to note that fact in the comment section where the idea was suggested by some such note as [--this has been incorporated], etc. Of course, new versions of the proposal are written out as the > version, and earlier versions are not normally deleted until they are backed up. If file forking occurs, it should be straightforward to do a "fair" SOURCE-COMPARE-MERGE. The last section of each proposal will be the STATUS section. This section will be supplied by the "project responsible" person or persons, who shall label their comments with their names and the current date. The section will summarize the offical project and/or company response to the proposal and the reasoning behind this response. Of course, the response itself may change also. In the event of significant change, those making the response should attempt to preserve a summary record of the previous responses and their dates. For example: 9/03/88 RG This is a good idea, but we dont have the resources to do it anytime soon ... 1/1/89 RG Now we should do this, in conjuction with ... XXX should begin work on it after he finishs YYY... Putting the Question and Closing If the originators of the proposal believe that the record contains sufficient information to serve as the basis of a decision, they may Put the Question. Actively Put Questions will will notated in the TABLE-OF-CONTENTS file, and project management is then responsible for updating its response, normally within two working days. If project or company managment believes that excessive company resources are being consumed by a particular issue, or believes that the company is irretrivably committed to a certain course beyond the point of useful discussion, it may CLOSE the issue. This really just serves as an advisory to company personel to minimize company resources spent on the issue. Obviously, persons wishing to reopen the issue should take it up with management. Resource Allocation: As a general rule, around 10% or so. I.e. if you are spending more than 10% of your time on hassling proposals, etc, think about whether it may too much. (Of course, we are in a major design or original proposal stage, then more may be appropriate.) Scope: The Official Company Plans which we plan to develop under this procedure are: Initial-Software-Plan: The company will port the LAMBDA software to the Falcon processor. Chip-Hardware-Plan: The company will supervise and approve development of the Phoenix Chip processor.