🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac.oop.macapp3
Article #76

Takeover - Scope

#76
From: Research SW Design, D Goldman,PR...
Date: Mon, 04 Jan 1993 00:12
62 lines
3357 bytes
 
----------------------------------------------------------------------------
An organization capable of supporting MacApp
properly would have to include at a bare minimum two programmers (one only and
you are at the whim of sickness, vacation, and the attractions of greener
pastures elsewhere), one documentation person, one QA person (two would be
better) and at least one full-time manager (better two, one technical and one
business).  And this is bare bones; it assumes, among other things, that tech
support is provided by the programmers, QA, and documentation folks; that
secretarial & etc. are part of some existing business structure; and that
training is provided by third parties.
----------------------------------------------------------------------------
 
Jeff --
 
Your idea of "supporting MacApp properly" is NOT AT ALL what I proposed in my
original message of this branching thread. What I DID propose was:
 
    I'm *not* proposing that MADA create MacApp 4.0. But wouldn't it be
    nice if there were SOMEBODY reviewing all of the bug reports and
    discussions on MacAppTech$ who would then actually change the MacApp
    source code accordingly?
 
Now, on a separate branch of this thread there is a discussion of how much
effort is needed to make a bug fix to MacApp. But if one accepts for a moment
that SOME percentage of bug fixes can be installed by a competent programmer --
working in conjunction with all of the developers on MacAppTech$ [why do all of
these discussions insist that all bug work and QA needs to be done in a
vacuum???] -- then to accomplish what I did propose would require a programmer.
Two, if you prefer. Period.
 
No documentation person. We're fixing bugs here, not creating a new system.
 
No separate QA people. That's the bulk of the programmer's job: take a bug-fix
already worked out on MacAppTech$ (or in Apple's existing bug doc!) and study
and test it. Put up a proposed fix on MacAppTech$ and let other brave souls try
it out. Put it on the next CD as a beta version.
 
No separate tech support function. If tech support means a place to get your
questions answered, the best place is currently MacAppTech$. If tech support
means a place to get MacApp bugs fixed, then we do not have any official tech
support at present.
 
No manager.
 
I agree that secretarial support comes from the existing structure, and that
training is not an issue.
 
 
Somebody used the phrase "keeping MacApp on life-support". That's what I'm
after. Right now the patient is bleeding from many small wounds, and Apple's
best response is to offer us periodic updates of a first aid manual (the Bug
Doc). And assure us that a healthier patient will be coming next year, along
with better health insurance (from a third party payer).
 
Why not transfer our current patient to a nurse who can read the first aid
manual and actually apply a few bandages?
 
-- Dave Goldman
   Research Software Design
 
Technical Details
Message-ID: <726106500.4047195@AppleLink.Apple.COM>
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!olivea!apple!applelink.apple.com

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!olivea!apple!applelink.apple.com
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Takeover - Scope
Message-ID: <726106500.4047195@AppleLink.Apple.COM>
Date: 4 Jan 93 00:12:00 GMT
Sender: daemon@Apple.COM
Organization: AppleLink Gateway
Lines: 62