home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 331 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  3.2 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!apple!applelink.apple.com
  2. From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Takeover - Scope
  5. Message-ID: <726106500.4047195@AppleLink.Apple.COM>
  6. Date: 4 Jan 93 00:12:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 62
  10.  
  11.  
  12.  
  13. ----------------------------------------------------------------------------
  14. An organization capable of supporting MacApp
  15. properly would have to include at a bare minimum two programmers (one only and
  16. you are at the whim of sickness, vacation, and the attractions of greener
  17. pastures elsewhere), one documentation person, one QA person (two would be
  18. better) and at least one full-time manager (better two, one technical and one
  19. business).  And this is bare bones; it assumes, among other things, that tech
  20. support is provided by the programmers, QA, and documentation folks; that
  21. secretarial & etc. are part of some existing business structure; and that
  22. training is provided by third parties.
  23. ----------------------------------------------------------------------------
  24.  
  25. Jeff --
  26.  
  27. Your idea of "supporting MacApp properly" is NOT AT ALL what I proposed in my
  28. original message of this branching thread. What I DID propose was:
  29.  
  30.     I'm *not* proposing that MADA create MacApp 4.0. But wouldn't it be
  31.     nice if there were SOMEBODY reviewing all of the bug reports and
  32.     discussions on MacAppTech$ who would then actually change the MacApp
  33.     source code accordingly?
  34.  
  35. Now, on a separate branch of this thread there is a discussion of how much
  36. effort is needed to make a bug fix to MacApp. But if one accepts for a moment
  37. that SOME percentage of bug fixes can be installed by a competent programmer --
  38. working in conjunction with all of the developers on MacAppTech$ [why do all of
  39. these discussions insist that all bug work and QA needs to be done in a
  40. vacuum???] -- then to accomplish what I did propose would require a programmer.
  41. Two, if you prefer. Period.
  42.  
  43. No documentation person. We're fixing bugs here, not creating a new system.
  44.  
  45. No separate QA people. That's the bulk of the programmer's job: take a bug-fix
  46. already worked out on MacAppTech$ (or in Apple's existing bug doc!) and study
  47. and test it. Put up a proposed fix on MacAppTech$ and let other brave souls try
  48. it out. Put it on the next CD as a beta version.
  49.  
  50. No separate tech support function. If tech support means a place to get your
  51. questions answered, the best place is currently MacAppTech$. If tech support
  52. means a place to get MacApp bugs fixed, then we do not have any official tech
  53. support at present.
  54.  
  55. No manager.
  56.  
  57. I agree that secretarial support comes from the existing structure, and that
  58. training is not an issue.
  59.  
  60.  
  61. Somebody used the phrase "keeping MacApp on life-support". That's what I'm
  62. after. Right now the patient is bleeding from many small wounds, and Apple's
  63. best response is to offer us periodic updates of a first aid manual (the Bug
  64. Doc). And assure us that a healthier patient will be coming next year, along
  65. with better health insurance (from a third party payer).
  66.  
  67. Why not transfer our current patient to a nurse who can read the first aid
  68. manual and actually apply a few bandages?
  69.  
  70. -- Dave Goldman
  71.    Research Software Design
  72.  
  73.