Revision 2.02

Preface
This document outlines the rules and regulations that govern the austnet. It represents the wills and support of a mass majority of the austnet community (users, opers and admins alike). It discusses the policy and guidelines which are enforced on the network, educating and promoting proper network usage.


Operators
  • Use of /KILL should be limited to providing a quick disruption of a broken or erroed client or one that is flooding or breaking server rules or abusing other servers/clients. This includes or could include a K:Line (local) or G:Line (network wide).
  • Client disconnection from the network is substantiated when:
    • violation of organisation charter agreement occurs
    • disruption of user's ability to IRC (harassing)
    • abuse of services or channel takeovers
    • flooding or clonebots
    • deliberate ban evasions
    • damage to servers, connections or physical hardware
  • Use of /SQUIT should be used only to reroute a server or in some cases jupe a server in co-operation or support of other online irc-operators or admins.
  • Before using /SQUIT, an operator is required to a) WALLOP the reroute with the online operators and b) /msg $.austnet.org to inform the general community.
  • Online operators are expected to have general knowledge about irc; if a user askes a question (basic help), operators are expected to politely attempt to help. If you find you are otherwise occupied, feel free to forward clients to #Help.
  • In the case of reroute or deliberate service interference, operators should /msg $*.org (or relevant server masks) in order to notify clients of the upcomming events.
  • General abuse or hassles with operators or servers should be presented to the server's administrator, and/or the Network Administration ([email protected])
  • An operator can have only one primary O:line at a time. This is considered to be their main server, and the one they use the most. This is also the person who is responsible for their duties.
  • An operator, however, can have as many secondaries as desired. These are not listed in server MOTD's and the operator must help the admin/oper contact maintain an accurate list of primaries and secondaries.

Server Administrators
  • The owners/admins of IRC servers are required to keep their server on-line to the requirements of server applications.
  • They are required to maintain and housekeep their server, upgrading the daemon when required and ensuring that the server is running at optimum performance.
  • Report outages, connectivity upgrades or the like to the Routing Department ([email protected])
  • Server Administrators are required to give Network Administration prior knowledge of O:line generation on servers at least 48 hours before hand. This is for administrative purposes, and so mail aliases, server information and the appropriate resources can be modified. This too, serves as a method of monitoring the operator count network wide and the ability for discussion over the O:line.
  • It is the responsibility of admins to see that their operators get the training required to perform well.
  • Any more than four O:lines (primary) on a server is highly discouraged unless there is a serious problem on the server that requires futher monitoring.
  • Server Administrators are required to organise connection lines with the Routing Department ([email protected])
  • The Server Admin is able to upgrade the server's machine or link, providing the machine remains in the same location, net-wise, or making other changes as necessary in keeping his or her server in the best possible working condition, where "best possible working condition" is defined at the discretion of the Admin.
  • Setting up an additional server to expand the capability of the site, even if this includes running additional processes on different machines, providing that the machines are of comparably capability, and the server's location does not change.
  • Do whatever is necessary regarding his or her own server, to be decided at the Admin's discretion, to make a smooth transition during hardware or software upgrades, or during an emergency situation.
  • An admin is responsible for the actions of their operators. If an operator causes problems which the admin cannot or will not deal with, the admin/oper contact will ask the admin to suspend the oper until the matter can be resolved.

Services Operators
  • Network Operators (100 service access) should attempt to mediate problems such as channel takeovers and channel floods, using the SETMODE and WIPECHAN commands.
  • Issuing operator status to certain users should be done *only* when a channel has lost ops for a reason *and* channel users are unhappy about it *and* they have decided upon who is to be opped.
  • A WIPECHAN should be used when a channel has been locked and set to +pstmil 1 or such similar mechanism (such as +b *!*@*) *and* channel regulars complain about it. In this case, the channel has to be cleared and nothing else. Ops will be decided as usual by the person who joins the channel first.
  • Service Operators (200 service access) are required to assist users in the legitimate recovery of passwords to their nickname.
  • Service Operators, in the case of channel or service abuse, are required to use the SUSPEND command to stop the management of a certain channel temporarily.
  • Channel suspension or removal as a disciplanary action should be posted to [email protected] as well to inform the network of channel management modifications.
  • Service Operators reserve the right to remove channel registrations when services have been abused. This is most likely the case when an operator on a channel registers the channel, and they are not supported by the current fellow operators. This is considered a channel takeover and should be investigated in depth.
  • All IRC-Operators are not subject to addition of service access.

Departmental Policy
The following Departments exist within the network:
  • Help
    The help department ensures that clients receive answers to their questions promptly, online and offline. Mailing lists such as [email protected] are established to assist users.

    Mailing List: [email protected]
  • Website
    The website department is responsible for the architecture and implementation of departmental and network web sites.

    Mailing List: [email protected]
  • Services
    The service department aims to discuss possible modifications and provide as a source of information in relation to channel and nickname ownership details. It is also used as a forum to which mediates ownership discussion.

    Mailing List: [email protected]
  • Public Relations
    The role of the Public Relations department is to provide documents to users about AustNet, ensure that the network is well advertised (for example, in search engines, client server lists etc). The Public Relations Department also aims to be a forum to discuss possible flaws within the network and puts forth possible solutions to implement that effect users.

    Mailing List: [email protected]
  • Routing
    The role of the Routing Department is a fundamental aspect of the network's connectivity. It's aim is to provide users with the best possible connection, along side a fast, efficient and stable network topology. The routing department is also in charge of network linkages.

    Mailing List: [email protected]

[About] [Services] [Connect] [Support] [Users] [Sponsors] [Contact] [Statistics]
Copyright ©1997 austnet.org. All rights reserved
For AustNet Support, mail [email protected]

administrative correspondence: [email protected] www.austnet.org correspondence: [email protected].