20 December 1998

Preface

Operators

• Use of /KILL should be limited to providing a quick disruption of a broken or errored 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
  1. WALLOP the reroute with the online operators
  2. /msg $.austnet.org to inform the general community.

• Online operators are expected to have general knowledge about IRC; if a user asks 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 $*.austnet.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 abuse response unit ([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/administrators 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 further monitoring.

• Server administrators are required to organise connection lines with the Routing Department ([email protected])

• The server administrator 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 administrator.

• 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 administrator's discretion, to make a smooth transition during hardware or software upgrades, or during an emergency situation.

• An administrator is responsible for the actions of their operators. If an operator causes problems which the administrator cannot or will not deal with, the administrator/operator contact will ask the administrator to suspend the operator 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.

Voting Policy

• Vote Roll
  All AustNet Administrators and global IRC Operators are given the option to vote for issues as they arise. Voting is a priviliage, and is subject to your vote participation. Voting will be handled by AustNet's vote server VoteOP.

• Vote Participation
  Anyone on the vote roll who does not vote for 3 votes in a row, may be subject to removal from that vote roll. (exceptions are those who are known to be away for a period of time). We need each and every vote, as most are often close, therefore having inactive voting members wastes time in having to call revotes.

• Vote Procedure
  Only those with level 300 access to AustNet services may place a vote, however admins may approach one of these people to request a vote for an issue they feel needs addressing.

  When a vote is placed, VoteOP will send a 'note' to all members on the voteroll, and an email shall be sent to the AustNet general mailing list [[email protected]] advising of this.

  Members on the voteroll shall place their vote before the vote closing date.

  When the vote closes, any votes made will be processed, a summary shall be posted to the AustNet general mailing list, and full vote details will be made available on AustNet's website.

• Vote Results
  Any abstain's made in a vote shall not be taken into account when deciding what the majority was. A votes outcome is determined only by the YES and NO votes. A clear 50% or higher majority is required either way.

  In event of a vote not having any clear outcome, a revote shall be called in 1 weeks time. This revote shall not allow any abstain votes to be made (to try to force some type of majority towards YES or NO).

  In the event of a revote being a tie, the CEO shall decide the outcome of that vote.

• Vote scenarios
  Testlink vote:
  • On event of a YES, server shall be given permanent AustNet server status.
  • On event of a NO, server shall be delinked and may re-apply to be a server on AustNet after a period of waiting 2 weeks.
  o: to O: vote:
  • On event of a YES, administrator has support of network to modify the person's o: into an O:. However, this is still the administrators choice, and may choose not to do that immediatly. The administrator may remove o:/O: lines anytime they wish without need for votes.
  • On event of a NO, the administrator is given option of leaving the person as an o: for a while (as the administrator does not have the network support to upgrade that status). The administrator may choose to drop that person as an o: too. A vote may not be called regarding that person's oper status until a period of 2 weeks has passed.

Departmental Policy

• 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]

• Web Site
  The web site 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. Its 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]

If you have Adobe Acrobat Reader, you can click on the icon to download this document in PDF format to print it.