Brown Computer Graphics Group
home
people
information
research
outreach
sponsors
search

Guide to Graphics Group Etiquette

Table of Contents


Questions
  • In the Books section, it says to post to graphics when you borrow a book, but this seems to have fallen by the wayside. Should we reinstate?
  • Videotapes section - is there an official place for the videotape db?

Introduction

The Graphics Lab is a well-equipped and comfortable place for doing graphics work and research, and we are eager to keep it that way. This document contains some suggestions for maintaining the physical and social atmosphere of the place, so that we can all work productively, and so that new people will be encouraged to join the group by what they see of us. It also contains some suggestions for maintaining good relations with the rest of the department and the university as a whole. These are not idle issues: our survival depends on the willing assistance of the astaff (Administrative staff) and tstaff (Technical staff), and on various arrangements that have been made with the campus police and others.

General

Personal issues

The graphics lab is not large, and often a great many people work in it at the same time. During periods of high pressure, there may be people working for long stretches in the lab, basically living there for several days in a row. This sort of environment requires good citizenship from its inhabitants. It is important that you maintain an easy manner, be willing to discuss things, and be open to the ideas of others. Intellectual obstinacy has no place in a research group: if your ideas are really correct, you'll be able to convince others of the fact.

Keep the general noise and clutter level down and pitch in to help keep the atmosphere friendly and relaxed - courtesy is contagious.

The telephone

When you answer the telephone in the lab and the person on the other end is looking for someone who you don't see in the lab, you should finger the person to see if they are logged in anywhere. That way you can tell the person on the phone if the person they are looking for is logged on elsewhere, logged in but idle, or not logged in anywhere. One particular way that you can enhance personal relations within the lab is to take good, clear, telephone messages. Send the message with electronic mail, and be sure to include the name of the person who called, and a number where s/he can be reached. If you are using someone else's account to send the message, be sure to include your name in the message. Also, if you do not send the message when you received the call, include the date and time of the call.

The phone can be used for local calls that have to do with lab business. Each call costs us about 50 cents. This means that if each person in the group makes about 3 calls per week, we spend 900 dollars during the academic year on phone calls. Please don't use the phone for personal calls.

Also, take a short while to learn how to transfer calls. Any one of the staff can explain it to you. Often you will need to forward calls to Andy (x7640 - learn this number now) or Spike (x7638). It demonstrates technical wizardry to be able to do this flawlessly, and our callers will be greatly impressed with your competence. If you are feeling flawed, directions should be on the back of the portable phone.

Cleanliness is next to godliness

Another consequence of the high population density of the lab is that we work close to each other. The ventilation in the lab is good (although noisy), but not good enough to remove unpleasant smells instantly. Please shower often, and don't come to work just after a game of street hockey without showering and changing. If, for some reason, you cannot use the shower at home, there is one adjacent to the graphics lab.

For the same reason, food which will leave a lingering odor in the lab is not a good idea. The kitchen is only a few steps away, and if you're going to eat a raw garlic and onion sandwich with pepperoni and Limburger cheese, do it there. Beware of throwing away foods in the lab trash cans on weekends - they won't get emptied until Monday afternoon. One other remark on food: if you bring easily distributable items like popcorn or potato chips into the lab and leave the bag around, you can reasonably expect to find that over the next few hours, others have walked by and munched a little; soon the bag will be gone. Of course, whenever you eat in the lab, you should remove the debris when you're finished. Also, be warned: Andy has a habit of taking a bite (or more) of whatever food he sees in the lab. He comes from a food-sharing culture, or so he says...

Outsiders

The lab attracts many visitors from around the world. Each of them visits because of an interest in what we do, and we should do our best to encourage this. (After all, last year's random visitor may be next year's grant donor). Be polite to outsiders, even those who just wander in. Offer them a demo, or at the very least, ask if you can help them with something or show them around. Everyone in the group should be able to show off at least one or two demos at all times, and give a brief patter about our work. This is good practice for more formal demos, since you'll become fluent in discussing our work, and will learn what sort of questions to expect from various sorts of people.

A particularly trying group of people are those who visit in the late winter and early spring: applicants or subfrosh and their parents. The future student may be extremely shy, in which case you might want to direct your attention to him or her, and ask about what sort of computer work s/he has done in the past, etc. The future student may also be exceptionally arrogant, which you should bear with equanimity. This is not easy, especially when you want to say "Shut up, you arrogant and ignorant fool!" Nonetheless, it is the right thing to do. Save the annoyance for later, when you can tell others in the graphics group what the kid said.

Physical space (The Final Frontier)

There is never enough room. For people who do not have their own offices, the file cabinets in the graphics room provide space to keep things. You should use these cabinets to store your property. Do not use the space around the machines for storing stuff. It looks messy, and in a very short time, books and papers end up on top of the machines (as do bags of potato chips...) and the machines will overheat. Of course, when you are at work you will need books and papers around you, but you should clean up when you finish.

The property that people keep in the filing cabinets is personal property. You should not open someone else's drawer without a good reason. You should never take food from someone else's drawer, or anything else except for group property that has found its way in there somehow (e.g., the Renderman manual). Conversely, the file drawers are not particularly secure, and you should not consider them a safe place to keep cameras, contraband, etc.

In order to make the space more pleasant, Andy has purchased a stereo for the group, and Spike has added a few items to it over the years. Usually, the members of the group manage to get along reasonably well with regard to musical taste, but if someone objects to some music, you should turn it off. You should also keep the volume down - people in the AI lab next door and in room 427 have complained about the volume at various times. If they do so, you should turn the stereo down or off immediately. We try to maintain good relations with the neighbors.

The physical space of the graphics room is pretty nice: we have comfortable chairs, a few posters, and good exterior light. It's easy to ruin a place like this by leaving a mess. Another way to ruin it is to break things, and this is best avoided by being careful. Watch out for other people's property, and avoid any sort of roughhousing in the lab. No one should play hockey, basketball, or other such games in the lab.

Neatness Counts

Please try to keep common property well-organized. Things do get messy, and everyone in the group should consider it his/her duty to spend an hour or two making things neater every now and then.

A special cleanup is required before any demo. Be prepared to be drafted as a cleaner-upper.

Books

As a research group, we try to stock a good library of graphics-related books, manuals, and SIGGRAPH proceedings and course notes. They cost a great deal of money, and we don't like having to replace them when they disappear. Please treat our books with care and try to keep them in the lab at all times. You never know when someone needs to look up the arguments to some obscure graphics function two minutes before making a software tape to send to a grant sponsor. If you absolutely must borrow a book, use the signout sheet that is in the bookshelf. Make sure you include your account (not your initials, if they are different), the name of the book, and when you expect to return the book.

Videotapes

We have a pretty decent collection of videotapes; some of them are originals with no copies and others came in our possession only after considerable begging with highly-placed graphics wizards around the world. If you want to use a videotape, please email the grips at least a day in advance if possible.

Dealing with problems

If your problem concerns:

  • Sun workstations: All the Sun workstations in the department are supported by tstaff. If a Sun machine has problems, or some system has problems, send mail to problem. Do not email problem about being added to a UNIX group or other related administrative requests (see below).
  • SGI's, PC's, or Macs: email gfxprob. Do not email that alias with problems concerning Sun workstations, see above for information on Sun problems.
  • Administrative requests: If you want to be added to a UNIX group, have a UNIX group created, have a new account sponsored, or any related task done relating to the Suns, do not mail problem, but mail Loring Holden instead.
  • Burned out bulb: email house.
  • Thermostat: If you want to adjust the thermostat, please contact Mark Oribello (mo) instead.
  • Special Service, such as using all the machines in the Sun Lab for one whole night, bounce the idea off of lsh, bcz, or some elder in the group first.

Security

Here are the rules: when the last person leaves the lab, the door should be closed and locked, the lights should be out, the stereo should be off, and the air conditioning should be on. There are two air conditioner switches; one is in the far right corner of the lab, and the other is near the door of the demo room. You pull the switch to turn on the air conditioning. Do not touch the power switch for the machines in the room - it's right next to the air-conditioner switch, and looks a lot like it, so check carefully. Someone once hit the power switch right before a demo, and the repercusions were not pretty. Everything turned out fine for the demo (there even is an interesting story about things were fixed), but it is better to avoid the problem.

Many of the screens on the heads for our computers have screen savers, which dim them after a short idle period. If you see a screen that is not dim when you leave the lab, turn it off. Certain machines may be left on for one reason or another. You should assume that all screens should be off, unless word to the contrary has been circulated around the Lab. Be careful to turn off the screen only, and not the power for the whole computer.

Because of the equipment and personal property in the lab, only graphics group people should be working there. Your friends may be great people, but you must not invite them to do their CS15 (or cs32, or...) homework in the lab. Kindly direct non-graphics people to the Sun lab on the first floor. If you have any problems with this, Andy and Spike are both quite happy to kick people out.

The combination to the lock on the door should be known only to users of the lab, that is, members of the graphics group.

The Campus Police are not eager to have lots of people running around the Campus at night, and they would probably love a good excuse to have all the academic buildings closed every night. Please try to give them no excuse: if a Security officer stops by the lab to ask if you've seen anyone suspicious in the building, help out. Say hello to the security guard downstairs so that s/he can get to know the faces of people who are likely to be working here late. It makes life much easier for everyone.

Graphics Meeting

The graphics meeting happens once a week, and provides opportunities for two things: Andy and Spike get to see what's going on with everyone, and we get to share ideas and schedule important events. It is the one really significant obligation you have in the group (aside from being reliable and productive, of course). You should not miss more than a couple of meetings in a year. If, for some reason, you cannot make it to the meeting, make a report to someone who will be there and can speak for you.

The meeting is usually on Wednesdays, 5:30 during the academic year and 1:00 during the summer.

Newsgroups

There are several programs for reading news: rn, some mode of emacs, etc. News articles are the means for transmitting important information around the department and the graphics group. Get familiar with some news reader, and some program that can post news messages.

There are two newsgroups that you should definitely read: brown.cs.graphics and brown.cs.general. The first is information relevant to the graphics group, the second contains information of general interest to the department. Many of you will also want to read brown.cs.grad, brown.cs.help, brown.cs.stupid.

Andy does not read news, for reasons that he can best explain. If you are posting something to the graphics newsgroup that may interest him, be certain to mail him a copy.


People

Andy (avd), Spike (jfh), David (dhl), and Nancy (nsp)

If any of the graphics faculty (Andy, Spike, David or Nancy) sends you mail, answer promptly. They're all reasonable folks, and will not get angry about petty things, but a lack of response is known to tick them off. There are lots of other graphics people

Trina Avery (kha)

Trina Avery is the person who is most directly responsible for keeping things running smoothly around the Computer Science Department. She is the person who administers grants, oversees the operations of the office staff, and generally knows what's going on.

She is also a wonderful editor, and when she is given adequate notice and time, she can turn manuscripts from ungrammatical and poorly written gibberish into clean, tight, precise gibberish: when she corrects a paper, she will often have little idea of the content, but her suggestions for rewriting will improve matters endlessly. She does small things like this for us gratis. If you have a thesis you'd like to have edited, she does such things free-lance, and at pretty reasonable rates. She does not do them gratis.

Trina also has a quick temper and a sometimes whimsical manner, and it is best to stay on the right side of both. If she asks you to do something, do it immediately. If you cannot do so, tell her so immediately. She hates having to wonder what is going on with things.

Jeff Coady (jwc)

Jeff runs the technical staff, which includes the software and hardware people. These folks are our lifeblood, and you should be nice to them. Offer the hardware folks a few of your potato chips, OK?

Jeff is an ex-Marine, and he's happy to let you know it. This means he likes things done in an orderly way, and through the right channels. I once saw him nearly bite the head off a student who reset a MicroVax one night when it was hung. Jeff is highly territorial about his equipment, and if you are fiddling around in a machine room, you'd better have a very good excuse. The only excuse I've ever seen as acceptable is prior permission.

Kristin Alsfield(kla)

Kristin is administrative assistant to Andy and Spike, and as such she has a very tough life. She almost always knows where Andy is, and how to reach him. If you want an appointment with Andy, talk to Kristin about it.

Video Users

Other people in the University helped to pay for the video equipment, and they will want to use it. Treat them nicely when they do, and be as helpful as you can about the video stuff. It's pretty intimidating the first time you see it. There is a general introductory document about the video equipment available.

If we have a demo going on, you should ask the video user to come back later, or at least try to resolve the conflict in some way - we should not let people just walk in during the middle of a demo and start using the equipment and borrowing tapes.


Work Habits

Window System

If you have no strong reason to deviate, please try to use the same window manager, editor, and aliases as the others in the graphics group. Your window manager should have an easily accessible menu item that kills the window manager and X, allowing others to log you out. (see /pro/graphics/startups/README for information about graphics group startups)

Standards and Documentation

Your programs should conform to the graphics group Software Standards, which are documented elsewhere. They should be documented according to those standards as well. If you leave behind poorly documented code, people will say bad things about you for years to come, and Andy and John will have a much harder time giving you good recommendations for grad school and jobs.

Documentation is also an important communication medium in our group; due to the large size of the group, it is often easier to refer people to documentation before getting into advanced discussions. Therefore, if you work on a BAGS/UGA package or command, you should keep the associated man page up-to-date.

Logging out

If you will be away from a machine for more than about 30 minutes, log out. If you don't, others may log you out if they need your machine. If you really need to remain logged in (to trap error messages to stdout or something), leave a sign on the machine saying so. This is not the Sun Lab, do not xlock your machine.

Signout

If you are leaving Providence for a while, use the signout command. This lets everyone know where you are, and how to reach you while you're there. When you get back, remove the expired signout entry. Be sure to check in any RCS files when you go away. If you don't, expect to get phone calls at odd hours...

Make sure your finger entry is up to date, so that others in the group can reach you. The plan that appears to Brown CS finger requests is found in ~/.plan, the plan that appears to people in the outside world is found in ~/.plan-external

Demos

Demos are given for various reasons, some of which have been mentioned above. When we give them, we try to appear excited about our work. Do not doze during demos.

Dress Code

During demos for people who might give us money, we tend to dress well. For men, this means jacket, tie, no jeans, no tennis shoes. Try to avoid avant-garde dress. For women, it means comparable things: skirts or nice pants, etc. No sweatshirts or sweatpants for anyone, OK?


Version history

  • 6/24/99 Various updates to update document
  • 6/23/99 Email gfxprob instead of mkd for graphics problems
  • 1/28/98 Changed "Problems with Hardware" to "Dealing with Hardware" and updated, lsh
  • 6/1/97 Updated document (people, meeting time, no "demo room", etc.)
  • 09/05/96 Translation to html and updating by lsh
  • ??
  • 09/13/90 Etiquette document, written by jfh, recalling the old etiquette document as best I can. [in nroff .me]



Brown CS Dept.STC HomePage
graphics web master,
gfx_www@cs.brown.edu