Group:
coordination system
Group:
debugging
Topic:
bugs
Topic:
commitment as a system
Topic:
examples of coordination systems
Topic:
management of large software projects
Topic:
programming environment
Topic:
software change management
| |
Subtopic: productivity 
| Quote: MONSTR improved project productivity with an orderly flow of information and responsibility among cooperating individuals [»knobK9_1981]
|
Subtopic: managing software maintenance by requests
| Quote: maintenance should be driven by the set of modification requests currently outstanding [»knudDB_1976]
| | Quote: all changes to #5ESS initiated by an Initial Modification Request to ECMS; implemented as deltas for one or more modification requests [»perrDE4_1998]
| | Quote: a Feature is the fundamental unit of system functionality; a set of Initial Modification Requests (IMRs) implements a Feature; one IMR to hundreds; may include hardware [»puruR6_2005]
| | Quote: an Initial Modification Request is implemented by a set of Modification Requests; one developer per MR, multiple IMRs and MRs per developer [»puruR6_2005]
| | Quote: features and change history managed by the IMR Tracking System; MRs and changes managed by the Extended Change Management System [»puruR6_2005]
|
Subtopic: workflow, bug state
| Quote: MONSTR illustrated the different states of software and the organizational division of responsibility [»mcgoMJ7_1983]
| | Quote: dispatching a MONSTR trouble report automatically sends it to the next organization in its protocol [»cashPM11_1979]
| | Quote: with a protocol, MONSTR can track trouble reports exactly, both inside an organization and in transit [»cashPM1_1980]
|
Subtopic: fault analysis
| Quote: fault analysis of the first 13 releases of an inventory tracking system; 500,000 lines of code, mostly Java [»ostrTJ7_2002]
|
Subtopic: bug tracking as conversation
| Quote: a MONSTR trouble report includes the record of a continuing conversation about the problem [»cashPM11_1979]
| | Quote: an automated trouble reporting system discouraged trouble-shooting conversations to identify the problem and its solution; ended up working around the system [»sachP9_1995]
| | Quote: the receiver of a software trouble report needs to know who sent it, under what authority, and what is expected [»holtAW11_1981]
| | Quote: MONSTR can report overdue responses to a trouble report [»cashPM11_1979]
| | Quote: may need to bundle software trouble reports to implement an ad hoc protocol; e.g., if part of a discussion [»cashPM11_1980]
|
Subtopic: bug tracking by routing
| Quote: automatic filtering/routing of email is immensely valuable; especially for advisory and bug-handling organizations [»boreNS9_1988]
| | Quote: the bboard andrew.gripes is heavily subscribed and a free-for-all; not useful for the Andrew Support Group [»boreNS9_1988]
|
Subtopic: bug sorting
| Quote: Andrew's Advisor system first tried automatic filing of messages by subject; 50% misclassification, too cluttered [»boreNS9_1988]
| | Quote: Andrew's Advisor system now sorts incoming mail by day; students process one day's messages and cross-post those they miss [»boreNS9_1988]
| | Quote: with human message sorting, Advisor can use fine-grained helpboxes that contain real requests; high-content and worth reading [»boreNS9_1988]
|
Subtopic: bug owner
| Quote: a trouble report is accepted on behalf of an organization but an individual is responsible; the acceptor's name is tracked [»cashPM1_1980]
| | Quote: a MONSTR trouble report always has an owner after someone accepts it; only the owner may alter it [»cashPM11_1979]
| | Quote: if the owner of a trouble report accepts a patch proposal, MONSTR will allow access to the relevant files [»cashPM1_1980]
|
Subtopic: related bugs
| Quote: MONSTR can report related trouble reports [»cashPM11_1979]
|
Subtopic: derived bugs
| Quote: Initial Modification Request closed after approval of its Modification Requests; a feature is done when all its IMRs close
| | Quote: a trouble report can be split into two with the original optionally cancelled [»cashPM1_1980]
|
Subtopic: canceling a bug
| Quote: MONSTR will not cancel a trouble report until the receiver agrees and all waiting organizations are notified [»cashPM1_1980]
|
Subtopic: other bug types
| Quote: a notice is like a trouble report without a protocol; either modification or cancellation [»cashPM11_1979]
| | Quote: a frozen trouble report can not be altered [»cashPM11_1979]
|
Subtopic: logging
| Quote: keep a running log to recover history of unrecoverable errors [»akscRM9_1984]
|
Subtopic: bug metrics
| Quote: half of Apache bugs are resolved within a day; much faster close times for high-priority problems; Mozilla much slower [»mockA7_2002]
|
Subtopic: problems with bug tracking
| Quote: once a user has processed a MONSTR report, no way to send a follow-up message about the same report [»knobK9_1981]
| | Quote: MONSTR globally classifies trouble reports; heavy users wanted a local classification scheme for organizing their work [»knobK9_1981]
| Quote: high numbers of killed or no_change modification requests indicate poor MR quality; waste of time
[»eickSG4_2002]
|
Related Topics
Group: coordination system (8 topics, 217 quotes)
Group: debugging (10 topics, 333 quotes)
Topic: bugs (66 items)
Topic: commitment as a system (22 items)
Topic: examples of coordination systems (23 items)
Topic: management of large software projects (63 items)
Topic: programming environment (46 items)
Topic: software change management
(48 items)
|
