1. Jay tried to have new software installed on the image, but he was told that they would not install it. It was PLT Scheme and he wanted them to install the latest version. The CSRs claimed that the had a policy against installing beta versions because it wasnt stable. He said he was a developer and knew it was stable, but they still wouldnt do it. He has responded to the image emails asking for it again this year. He will contact us if he gets the same response this time, but we ought to track this and make sure it happens. This seems like a reasonable request.
2. Many people mentioned that they had things done by the CSRs and they didnt test what they had done
3. Many people said that the CSRs try to close tickets instead of resolving the problems.
4. Several people said that they just want things to stay the same. Should there be a way of keeping a set of services between semesters. Maybe a set of regression tests that would make sure that new installations still run existing applications.
5. Cory Barker would like to find way to tighten down permissions on our NSF file system as it relates to students who have taken prior CS classes and have project solutions sitting in home directories. Cory has found situations where new students troll directories of older (prior) students and take solutions from open directories.

We almost escaped needing to meet Monday when Parris left us off the agenda for the retreat; sadly, Parris has since corrected his oversight, and he is asking us to spend 20 minutes talking about what we have done, what we do, and what we are going to do.

Based on all the responses to my previous email, let's plan on Monday morning at either 8:00 AM or 10:30 AM to meet. Send me your preference today, and I will finalize the time this afternoon.

Rough Presentation Outline with assignments to prepare material (goal is to educate faculty):

• Klark and Loren: Internal resources (new machines and services)
• Klark: The usage of our labs (typical loads and live status page)
• Loren: The types of problems we most often face
• Loren: The volume of help we provide
  • Quick ticks (go and get myself)
• Committee: The direction we are headed over the next 3 years.

Thoughts? Additions? Deletions?

• Recognize problems from last year that should not repeat: finalized construction and power. Tough year with a lot of painful work: kudos to Kevin, Klark, and Loren

• Summarize responsibilities of computing committee in a few slides
  • Provide virtual servers
  • Lab images
  • Wiki
  • Accounts
  • LDAP
  • DNS
  • Email (Faculty)
  • Web server (virtual server through Loren)
  • Help desk
  • Ticket system
  • Wireless service
  • Wired service
  • Firewall/proxy

• Strengths
  • Help desk and ticket system – be sure to keep us in the loop
  • Quotas are up (and they will go up again)
  • Dedicated machines for remote access through schizo entry point (blocking certain labs from remote access and funneling all off campus through schizo).
  • Auto-log-off scripts to enforce open lab hours.
  • Tickets are regularly reviewed

• Weaknesses (open for input from faculty)
  • DHCP and network resources not always easy to use (new machines etc.)
  • Disconnect between the product we present with virtual services and the reality of bringing those online.
  • Wireless coverage is not complete and sometimes fickle
  • LDAP is a thorn in our flesh – believe it is resolved
  • NSF (not always helpful) – believe it is resolved
  • Missing redundancy – working to correct that with the new servers

• Challenges:
  • Staff (building IT on students is not always easy)
  • Communication between end users and staff — need to focus on the ticket system
  • Volume of students and accounts that flow through the department each semester
  • Diversity of needs in the department: no two labs are the same
  • When something does go wrong, it is often “critical” and needs immediate attention? Many of these can be avoided with better communication — lab images are a great example. Trying to solidify the images, but the response is slow. Need more immediate feedback. Difficult to be responsive with so many demands (and all are on fire).

• Direction
  • New machines are moving to virtual desktops (students can pick any OS in any given lab)
  • Focus on core services and make those core services absolutely reliable
  • Openness in what is (and is not) provided in our services
  • Group support.

• Why not let BYU manage our resources? What are we providing that OIT cannot (does not) provide?
  • Policy
  • Cost (OIT is not cheap!)
  • Service is a concern with OIT (consistent message from meetings)

• Why not pay someone else to do it offsite (i.e., google mail, off-site storage, svn, etc.)?