[60] in Layered Athena
Layer Team Meeting Minutes of 7 Jul 94
daemon@ATHENA.MIT.EDU (brlewis@MIT.EDU)
Sat Jul 9 16:06:48 1994
From: brlewis@MIT.EDU
Date: Sat, 9 Jul 94 16:05:27 -0400
To: layered-athena@MIT.EDU
Present: brlewis, carla, kcunning, othomas, nschmidt
Next meeting: July 21, 9:30am in E40-316
DCNS-DEV COMMITMENT
brlewis: dcns-dev is ready to implement Layered Athena on several
platforms this summer...all three supported Athena platforms plus Alphas
and HP's. tjm has a draft document detailing our commitments on all
Unix platforms.
nschmidt: Getting release 7.7 out is important to my customers. Don't
let release work suffer in order to get Layered Athena out quickly.
(others agree)
ACTION: brlewis will relay this concern to dcns-dev.
nschmidt: Could that draft document be finalized?
ACTION: brlewis will ask tjm to finalize "Supported Unix Platforms and
Future Commitments".
kcunning: Are developers going to change the design of L.A. for
their specific platforms? What's going to be different?
brlewis: The design should be the same. The xlayer program will
definitely be the same, although different items may be grayed out
(e.g. Andrew on Alphas and HP's.) There will be some temptation to
redesign.
ACTION: brlewis will coordinate developers, and point them at the latest
design doc.
kcunning: A while ago, we decided to do a prototype on one platform
before proceeding to a large-scale project. Has this changed? Is it
wise to proceed on multiple platforms considering the moderate amount of
testing Layered Athena on Ultrix has gotten?
brlewis: If, as a team, we decide we really can't handle more platforms
yet, we can say "Don't do it," or "Do it if you want, but we're not
ready to do anything with it." However, there's a lot of confidence now
in the concept of having a simple interface for choosing subsets of the
Athena environment, and there's a great potential benefit in having the
development work done on several platforms early on.
brlewis: Success depends on our ability to pull off a successful
multi-platform beta test program. If we don't support customers well
enough, or people feel "burned" by Layered Athena, it will take a long
time for LA to be accepted in the community.
(Other concerns were raised. Hopefully most are addressed in the
Affinity diagram (KJ) we started.)
The team began work on an Affinity diagram on the topic, "What are the
issues involved in supporting a multi-platform beta test program?" We
will continue work on it at the next meeting. What follows is an
outline of what we have so far. Groupings that we don't yet have
headers for are labeled "Grouping 1", etc.
Timing/Scheduling
* Do we need to settle policy questions before starting the beta
test?
* We need to time the beta test so as not to interfere with fall
startup.
* How long should the beta test last?
Proactive Support for Active Beta Testers
* Docs needed:
- install gude
- indiv. docs by subset?
* One document or many?
* info available
- online < various means
- paper < various sites
* What kind of training?
- end user?
- installation?
- are these the same?
* How much info to put into the Layer Athena client (pop up help)
* How will we let people know when a currently grayed-out item
becomes available?
* How to get online help info to users if "Appl." subset not loaded?
Machines and Tools for Adequate Support
Grouping 1
* remote queries of machine config? since no test machines.
* easy, universal way to determine your configuration re: L.A.
* relationship of L.A. with other platforms (e.g. Macs/DOS,
etc.)
Grouping 2
* Availability of working platform types (machines) for support
groups
* No local test platforms to duplicate problems
Feedback/Data Collection
* Is the beta-test to concentrate mainly on
installation/de-installation or on ongoing use?
* What data do we want to collect during the beta test?
* How do we get feedback on overall satisfaction of customer?
* We'd get different types of feedback from single user or multiple
user machines.
How Do We Lure and Reassure Potential Testers?
Grouping 1
* How many sites?
* How do we find beta-testers on all these platforms?
* How will we find enough beta testers?
* Relationship at point of sale for newly purchased machines
(e.g. mcc)
Grouping 2
* Will de-installation be robust?
* We must guarantee that software will de-install?
How Do We Prepare and Coordinate Those Who Directly Support Testers?
Grouping 1
* Developers should feel that providing information to us is a
responsibility.
* Coordinate developers with each other -- in a locale visible
to support groups
* Are all involved developers prepared and willing to take
questions?
* How do we handle bug reports?
* If customers are upset because there is no support, who will
deal with them?
Grouping 2
* Can consulting handle a beta test of this complexity?
* Coordinating support groups roles
* What groups beside Consulting need to be involved?
* mail interface to OLC (was this fixed)?
* L.A. OLC topic (etc.)
* If consultants will only be able to say "type this command"
should we still have questions come through OLC?
* Managing information about "what is Layered Athena" as it
evolves.
Grouping 3
* How much staff training? (how much FTE to support users)
* Training of RCC consultants
* Training of MCC consultants
* NSS training, preparation
How Do We Set Realistic Expectations
Grouping 1
* How do we deal with the perception that one should take Athena
because it gives you lots of free 3partysw?
* We need to set expectations about what layered Athena gives
one
* If 3partysw is available, do we want to restrict its use on
the honor system?
* How complex can the machine to be layered be?
Grouping 2
* Know & catalog diffs between L.A. and "regular Athena"
* Will L.A. versions of Athena software idffer from "regular"
versions (will we need to keep track of multiple versions of
software on same platform)
Vendor Support in a Layered World
* If a 3rd party s/w problem can't be duplicated on a
non-layered athena machine, we may not be able to provide help.
* Will OSF/1 or HP/UX be able to still get help from vendor if
they're running layered athena?
