Attending: Bill Auld, Pakis Bessias, John Board, Janis Curtis, Jim Dronsfield, David Ferriero, Nevin Fouts, Betty Le Compagnon, Kevin Lee, Roger Lloyd, Melissa Mills, Caroline Nisbet, George Oberlander, Mike Pickett, Charles Register, Alex Reutter, Rafael Rodriguez, Bill Scarborough, Marion Shepard, John Sigmon, Roy Weintraub, Robert Wolpert

Meeting called to order 4:10 by Robert Wolpert (RLW)

Review of Minutes: minutes okayed

Announcements

4:12-4:14

Betty Le Compagnon (BC) : The next meeting we'll be discussing planning for a model of computer support at Duke, and issues involved in organizing the plan.

Mike Pickett (MP) : The procurement project is changing leadership with the departure of Dick Siemer. Tallman Trask will take over as the project leader. He has engaged an outside consultant to review the production readiness of the project.

Jim Dronsfield (JD) : We'll be back in our old room soon, perhaps by September 1st, since the OIT renovation is on schedule.

Desktop Renewal Paper

Discussion begun 4:15

Janis Curtis (JC) : Thanked the members of her DUDTRPP group; and explained the main points of the paper:

Concerns with distributed computing:

  1. missed opportunities for savings
  2. interoperability problems
  3. problems with data sharing
  4. increased burden on the network

Essentially, the difficulty with a distributed network is that it makes the task of aiding and abetting research, teaching, and patient care more difficult and costly. The three key issues at hand are:

  1. Total cost of owning a PC
  2. The life cycle of the PC
  3. Setting of standards

With the rising cost and shrinking useful life cycle of the PC, the group recommend setting certain "standards" that would allow computing at Duke to move smoothly.

Melissa Mills (MM) : Asked about the wording that makes the "personal" computer into a "shared" environment. While technically absolutely correct, she was concerned that "depersonalization" of the computer will make it difficult to get already computer-nervous persons to believe the computer is a pet and not some wild beast.

Nevin Fouts (NF) : Responded that the wording conveys the idea that asking each person to maintain their own computers is untenable.

Roy Weintraub (RW) : Teaching, research, and patient care are the main purpose of the university, and the document needs work to acknowledge this fact. A strict framework cannot be imposed on the university, no matter how well intentioned if it will interfere with these goals. The document needs to account for professional freedom to use any hardware or software a person chooses.

George Oberlander (GO) : Moreover, the idea of "inter-operability" is unclear, and needs defining within the paper.

JC : As explanation to RW's concerns; the idea is not to restrict people's freedom to choose their own system; it was assumed that the purpose of computing is to support research, teaching, and patient care. If a member of the university wants to do something with a computer, we want to be in the best position possible to help them do whatever that thing is, and so _some_ sort of infrastructure needs to be in place.

GO : But rather than standards, we should advocate a "trickling down" of machines from computer intensive departments to less intensive departments.

BC : The process of how to accomplish that needs discussion.

Rafael Rodriguez (RR) : in agreement with GO and that the various problems change and depend heavily on the class of user involved.

MM : Where do the schools fit in? Recommendations by schools/ class of users, however defined, would be helpful. We need to decide how we feel about support, before we send the wrong message to the Senior Officers; we don't want to cut back support, and maybe we're not spending enough!

RLW : Is it the case that different users really are quite different cases?

(general agreement that they are)

MM : In A&S we are constructing a decision tree to help people decide what kind of machine to put on their desks. This exact tree may not work for engineering, but the idea is sound. Overall standards are okay, so long as they are modified by school, or department.

BC : So then the key issues affect everyone, but the answers to those issues are different?

(general agreement)

GO : How often will standards change? Quite often, probably. We don't want to have to rewrite the standards every year or two. It would be better to figure out "when do you need a new machine", then move it along to someone who could still use that machine...

MP : We need to recognize that everything has a life cycle and try to "freshness date" our recommendations.

(discussion followed on restrictiveness of "standards", shrinking the diversity of computers.... JC noted again that the idea is not to restrict absolutely, but to give guidelines that will aid support)

JD : This paper just accounts for Duke-owned machines. There are a significant number of student-owned machines that are hooked up to the network.

BC : What is the bottom line for when I meet with the Senior Officers?

NF : "Standards" enable faculty to do what they need to do.

Caroline Nisbet : Some of the discussion of "classes" of users needs rethinking. Separating users into academic, administrative, student etc., just isn't reasonable! There will be students who have computing needs more similar to faculty than to other students and vice versa.... We need to think about classes of users by what we do, not by our "position" in the university.

(short discussion of "cost" of PC's, and what to tell the Senior Officer's; can we give them a number for every kind of user? General consensus - NO)

Discussion ended 5:00

Administrative Reform

Discussion begun 5:00

MP : Explained how 2 drafts came into existence and finished asking, "What ideas do we want to take forward from this?"

MM : We should communicate that positive things are being done and not everything is messed up. For instance, we are helping people to choose computers, the coordination between groups is getting better, and certain costs are starting to decrease. We've started changing and it should be noted as such. "It needs to evolve, and is evolving."

GO : We need to be pragmatists, and need backup plans. There may be cases in which we DO want to build rather than buy.

RLW : However, the "buy don't build" is a reminder to those in later generations of the blood spilled in earlier times.

GO : The important thing is to be able to justify why you're doing something. Identify the costs and benefits.

BC : We're will be influencing the Senior Officers, and so we must be careful in the message we give.

RLW : Is everyone happy with the structure of the paper?

(general consent)

BC : Let's keep the structure, and ask Roy to integrate the two drafts.

End discussion 5:20

Email Changes

Discussion begun 5:20

Charles Register (CR) : A summary of the changes has been posted to duke.computing. In essence, we're switching to IMAP4. This will take about 18 weeks to finish the conversion of all the accounts; hopefully nothing nasty will happen. A test group will be switched over, and if nothing bad happens, then the rest will be switched more quickly.

RLW : I appreciated tone of newsgroup messages, which stressed the good things about the IMAP4 configuration, rather than the bad things about the old programs.

CR : Some of the old programs (the ones that don't support IMAP4) will die. In addition, IMAP4 will allow us to, for the first time, institute quotas on mailboxes. They are not meant to be restrictive, but mostly to help foster responsible virtual citizens. The quotas are set at 10 Meg, which includes _all_ received mail folders, not just the inbox. Every attempt will be made to accommodate heavy e-mail users.

MP : We are seeing a continuously high rate of growth in email. Also, cc:Mail is dying, and a lot of the users are expressing a preference to migrate to NotesMail. It offers people a similar mailer that has a better technical infrastructure.

Other business

5:27

John Sigmon (JS) : We've negotiated a site license for ARCINFO. I'll bring information to the next meeting for us to discuss

(general murmurs of interest)

RLW adjourned meeting at 5:30.