SCCS Policy Board Document

SCCS Policy Document

Major decisions of the SCCS policy board. Note that all dates are in the form

Item 1: Policy board operation

Policy board meetings will have a loose parliamentary structure; the SCCS president will normally serve as speaker. The board may appoint a different speaker for a meeting or a series of meetings. Our goal is to write a single, unified policy document. We will publicly archive all meeting minutes. All votes and other policy board actions will be recorded in a diary.[95.9.28] [addendum 95.10.31: that diary is simply a log of the policy mailing list; minutes need not report a roll call vote, only the final result]

The new SCCS constitution allows the sysadmins a veto on any matter other than sysadmin removal. In respect of this, either of the sysadmins on the board may request that we delay any action until the sysadmins have a chance to veto it. [95.9.28]

Any policy board member can raise an issue to the policy board list ( requesting quick attention. The next twenty four hours (more or less) can be used for discussion, and any member can request that the matter be put off until the next physical meeting. If no one requests the delay, the president will issue a call for votes. Votes will be mailed to the president who will then summarize the votes (with attribution) to the policy list. If the matter is particularly pressing, the president can announce a result based on agreement of three members even if not all five have voted.[95.9.28]

Abstentions (and tie voting):

Normally actions take three votes to carry. With abstentions, only a simple majority is required. [95.10.31; temporary, pending reference to parliamentary procedure]

If a vote ties as a result of abstentions, we ask, but do not demand, that any members who abstained participate at their discretion and vote again. If we're still tied, we send a message to all officers and sysadmins NOT on the poliy board stating the different opinions on the board and asking for a) comments, and b) how they would vote on the same matter. In light of their input, we vote again. And if we remain tied, we accept the vote of the officers and sysadmins not an the board, allowing each one vote. [all adopted 95.9.28]

The policy board may appoint a subcommittee of itself to handle reviews of current sysadmins. [95.10.10] All discussion of sysadmin candidates will be stricken from staff and policy board diaries. [95.10.31]

Item 2: Usernames

We will allow usernames that consist of:

[accepted 95.10.5]

Added to this are
Additionally, we allow whimsical nicknames in the middle of the real name (GECOS) field. The sysadmins may reject any such nicknames they find offensive, but the user may appeal to the policy board.
[E-mail vote 95.10.10]
In the above phrase, "widely used uncommon nicknames", we define "widely used" to mean recognized or used by the swarthmore community at large. An example of this is if professors recognize the student by this name.

We would like to recognize that particular existant usernames are not consistent with this policy and are considered "grandfathered". We cannot retroactively apply this policy clarification to existant usernames. [adopted 99.02.08]

Item 3: Disk usage

(to be removed) Non-sysadmins are limited to 10MB of files. All files including web pages and mail spool are included in this limit [95.10.10]. Non-sysadmins are limited to 20MB of files in their home directories. A "soft quota" of 20MB is also enforced for people's web-docs directories. Users with legitimate web-docs needs larger than 20MB may appeal to the SCCS Policy Board for an increase in disk quota size.
[adopted 98.12.01]

To enforce limits, sysadmins are instructed to:

[adopted 95.10.10]
[updated 98.12.01]

Item 4: Account Guidelines

SCCS Users are expected to comply to the following guidelines. SCCS Users will be informed of these guidelines through an e-mail message sent during new account creation.
[added 98.12.1]

Item 5: Guideline Enforcement

Given reasonable suspicion that a user is violating the usage guidelines dictated above, a sysadmin at his/her discretion may take any necessary actions to enforce these guidelines and ensure the safety and securty of the system.

These actions include anything up-to and including the immediate freezing of the suspected violator's account.

Once these measures have been taken, it is the task of the policy board to adjuciate the matter and decide upon a reasonable disciplinary action.

The policy board must meet within a week of the incident to decide upon a course of action. This decision must subsequently be e-mailed to all parties involved, including the SCCS staff.

The suggested course of action for guideline violations is to place the user on disciplinary "probation". The users account may be un-frozen subsequent to the user appearing in front of the policy board to explain themselves and recieve judgement.

More extreme measures including the immediate cessation of account priviledges and subsequent removal of account information may be taken if dictated by the circumstances.

The user may appeal the above decision at the next meeting of the policy board.

[added 98.12.1]

Item 6: disabling accounts

We recognize two pricipal levels of account "freezes":

Methods of disabling accounts:

Disabled accounts should have the password field in /etc/passwd "starred out" to prevent use of the account via ftp. [95.10.10]

Web pages should be locked as inobtrusively as possible. If practical, server config fiels should be changed. Otherwise, the user's web-docs (or similar) directory should be moved to, say, web-docs.frozen, rather than having its permission changed.[95.10.31]