[72] in Kakapo Windows Team
Re: Meeting 8/21 w92-199
daemon@ATHENA.MIT.EDU (Oliver Thomas)
Wed Aug 20 17:48:08 2003
Date: Wed, 20 Aug 2003 17:48:04 -0400
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Oliver Thomas <othomas@mit.edu>
To: kakapo@mit.edu
From: Oliver Thomas <othomas@MIT.EDU>
In-Reply-To: <5.0.2.1.2.20030818090914.01657330@po12.mit.edu>
Message-Id: <FA7CFEF4-D357-11D7-8300-000393A3632A@mit.edu>
Content-Transfer-Encoding: 7bit
> If Oliver can produce the blurb on Container Admin. Request process
> and tool beforehand, we can hopefully bless it at this meeting.
Okay, the proposed process in all its simplistic glory is this:
1. Choose one of:
a. I am already a container administrator in WIN.MIT.EDU
b. I have already received counseling regarding use of
WIN.MIT.EDU and just need a container
c. I am completely new to the game
2. Depending on the choice made in (1)
a. For (1a) and (1b) the container request goes straight
to hesreq and the container is created (expect < 1 day)
i. We will wait to see if this creates abuse by the
(1b) people
ii. If yes, we may ACL (1a) with certificates to
contact-container-admins and special-case the
(1b) people
b. For (1c) the request gets routed to Kakapo and counseling
by Admin (DITR/Theresa) or Academic (Chad/Phil) liaisons
happens.
3. Follow-up and Escalations
a. Escalations generally go to kakapo@mit.edu
b. If a status request comes in from (1a) or (1b) people
we check in moira if the container has been created;
if not, we yell at hesreq
c. If a status request comes in from (1c) people kakapo
is at fault/on the hook for moving this forward
d. If (2b) determines that a container on WIN.MIT.EDU is
the right thing, the liaison should submit the container
request on behalf of the customer
There is a draft form at http://web.mit.edu/othomas/www/win/1.html
I found that it was easier to do (1) by splitting the form into two
parts. The second part looks different depending on whether you choose
(1a/1b) or (1c). The second part for (1c) is my take at a
"project/cluster" form.
Please review the pages carefully. Most of the help and standard
container request form stuff was taken from the current form, but the
cluster stuff needs heavy revision.
Also, I made the "decision" that every container-admin list should also
be a mailing list. The form sets expectations to that effect. The
customer can go in later and turn that off, but I think the cases where
you legitimately only want a group are fringe and should take a back
seat to the our need to be able to escalate problems with particular
containers to the appropriate admins. We can discuss this tomorrow.
Oh, I also made up arbitrary targets for when customers should expect
to hear back. 1 b-day for straight requests, 5 b-days for new
projects/clusters. We should discuss these.
Do we want different phrasing on the first page to steer people who are
already admins but may want more extensive advice on a project to
option (1c)?
Cheers,
Oliver
