Xref: utzoo alt.comp.acad-freedom.talk:71 comp.admin.policy:292 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!vtserf!marchany From: marchany@vtserf.cc.vt.edu (Randy Marchany) Newsgroups: alt.comp.acad-freedom.talk,comp.admin.policy Subject: Re: Ohio State University CIS Policies Message-ID: <1874@vtserf.cc.vt.edu> Date: 5 Jun 91 02:07:40 GMT References: <1991Jun4.160947.7193@eng.umd.edu> Followup-To: alt.comp.acad-freedom.talk Organization: Virginia Tech, Blacksburg, VA Lines: 67 In article sbrack@bluemoon.uucp (Steven S. Brack) writes: > I made 15 phone calls to 10 different people, not counting > being transferred all over campus. > Apparently the policy of our system administration is to keep > students from solving problems on the local admin level. My > account priveleges were restored after I met with the chair > of the department that owned, but did not manage, the system in > question. My telephony took me all the way from my professor > to the local system manager to the director of Academic Computing > Services, then to the Dean of the Engineering College. I finally > called our University Ombudsperson, who helped me determine who > I should have been talking to, as none of the people I talked to > directed me to the right place. > Geez, this run-around is really inexcusable. What we have here is a failure to communicate not with the user but with the administrators. I think we need to split the issue into separate parts. One purpose of a "policy" statement is to clearly spell out the points of contact for various issues. A single page containing phone numbers or "account mgrs", "user consulants", "technical support", "sysadmins", "the owner" handed out when a user gets an account on a machine or an online version of this list available to the entire computing community of that system(s) or network would reduce the frustration level of the users tremendously. Look at it from the user's point of view, who do you contact if you think someone is messing with your account/data? Having such a simple document would avoid tension between the users and the sysadmins. The second purpose of a policy statement is to CLEARLY delineate the responsibilities of the various personnel mentioned in such a "hit list". Again, this document should be available to the user community (preferably an online version). I stress that individual names are not important, the "job title" is what should be defined. The third purpose of a policy statement is do DEFINE the computing environment for a particular site. Whether you set up a wide open environment or a restrictive one must be defined in this section. The users agree to abide by the "site rules" by implicit means ("by logging on this system, you agree to operate in this environment") or explicitly, i.e., the user signs a form which states he agrees to "play by the rules". A lot of these issues used to be "taken for granted". Of course, the problem is that what one person "takes for granted", another might not. The problem of NOT defining a site's particular policy has been around for years and has caused the usual amount of friction between users and system managers. Clearly, one document that discusses the three points above may not pass through the local political process. However, a series of documents, each covering a separate aspect of the OVERALL scheme has a better chance. Once the statement(s) are put together, they need to be made available to the users. By not doing this, sysadmins and their bosses fail in their responsibility to the user community. Quite frankly, sysadmins are like cruise ship captains, You run passengers thru the lifeboat drills, give them the "house rules" and let them go to have fun or act like jerks. The key issue is that you (sysadmins/owner etc.) spell out what you expect, what to do in emergencies and who to contact. -Randy Marchany VA Tech Computing Center Blacksburg, VA "my opinions are my own."