Loren, Mark, Klark, Gordon, Eric, Dan

;Reports: What is the top priority for the each of the sub-committees through the first quarter of 2010?

;Priorities through 2010Q1: ;# Open lab images are validated and stable well before a semester begins — define and debug the process i)Changes submitted prior to finals; ii) Finals week devoted to testing ;# Prototype a “virtual” lab in spring semester supporting any of our operating systems from any machine (Windows and VM client in Linux Host — trial Winter) ;# Group and project support ;Open lab names: Should we be using internet sites for open lab machine names — google.cs.byu.edu, etc.? — Not the ideal theme, but not worth the energy to change. Themes fine.

We need to establish a “prioritization protocol” that clearly lets CSRs/help desk folks know how to prioritize tickets and help requests. This should be a concrete, open decision making process that is based on the priorities that our committee has set and perhaps on faculty feedback. To make this happen we need to:

: 1. solicit feedback on this from faculty – what do they think should be the priority?

: 2. “operationalize” this, along with the prioritization scheme we've begun formulating in committee – we need to turn it into a concrete decision making process.

: 3. publish this to the entire department so faculty, students, etc. understand just where their request will fall in the priority queue.

;Priorities through 2010Q1: i) DHCP working as expected; ii) faculty survey and set of solid verified services (pull pet-peeves from survey.

I spent some time talking to a few faculty members about their impressions of the department infrastructure. Here are a few of the things they are saying:

• I think we underestimate the impact of losing the wiki data. It made faculty members feel like they cant trust anything in the department infrastructure. Some of them are now paying an off-site hosting service even if they didn't lose any data personally. It is like any customer service area … when someone has a bad experience they tell all of their friends, but when they have a good experience nobody hears about it. I think everyone in the department has heard about it and is shaking their head and doubting department infrastructure.
• Although it may have been a while ago, the feeling is that the department mail is unreliable and people are moving away from it. I think we either need to prove that it is reliable or drop it as a service. It seems to me that it is kind of the ugly stepsister that nobody really pays attention to unless it goes down. If we are going to provide mail as a service, we need to be constantly monitoring and testing it and testing the backups to make sure we never lose anything and have totally reliable service.
• A lot of faculty are plugging into their phones for networking in their labs because they have had an experience with the department network being flaky. I have had the same experience. Even last week, I was having trouble trying to access a page on the department network, I switched over to the back of my phone and everything worked. I have had times when over a period of hours I was getting in the 50KB/sec in the department and when I switched to the back of my phone I was up at 10MB/sec. I would like to install mrtg. It talks to the routers with SNMP and gives you a record of what is going on. Then when someone has trouble we can at least look at the logs to see what is happening. We need to move from asking the faculty to prove that there is a problem, to proactively installing monitoring tools to let us diagnose problems before they ever see them.
• I asked about what faculty would really like in terms of support for their research labs. I would like to put together a survey to see if this extends to the department as a whole:
  • A web server (with ftp) where they can install content that it backed up and totally reliable that they dont have to spend student time maintaining. All the security patches and installation are done by someone else, but they have the ability to modify content. I think we could provide this with the resources we currently have. I dont think they really want a virtual server that they have to configure and maintain.
  • svn and wikis, but these are secondary
  • I think that most faculty have given up on department email. I think we should can the service and set up a way to service cs.byu.edu addresses externally. It is too hard to maintain reliable email when we have a small number of users. This will get worse now that students arent included.

Mark