Preface
This document outlines the rules and regulations that govern the AustNet IRC network. 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 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
- WALLOP the reroute with the online operators
- /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.

Operators are considered network staff. As such, they may change primary O lines with the consent and prior notification to [email protected] by the admin adding the operator to their staff, and no objection by another administrator within 48 hours. If there is an objection by another server administrator, a vote must be called.

Operators coming in with a server that then delinks will lose their O line unless approval and a move occurs within 7 days of the server delinking. In the event of a vote, no operator who has a current vote pending (including the operator who is the subject of the vote), may vote to ensure fairness.

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.

Each administrator may add one local operator for training to global provided that:
- [email protected] is notified at least 48 hours prior to the generation of the local o line, AND
- no other server administrator objects to the addition
If an objection is lodged, a network vote may occur to allow the addition. The trainee must remain local at least 4 weeks, though 6-8 weeks is recommended for most cases. After that time, the administrator may request an o: -> O: vote. If successful, the operator will be added to staff, is considered network staff, and may be added to Sprint/OperOP/VoteOP. If unsuccessful, they may remain local, or be removed, at the administrator's discretion, but no vote may be recalled for at least another 4 weeks.

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.

Routing Department Policy

Testlinked Servers:
The administrator of a Testlinked server is allowed to be global O:, in order to facilitate evaluation and encourage more familiarity for both the network and the new administrator. The administrator has the following limitations imposed:

they will not have Sprint/OperOP/VoteOP access during the testlink;
should not reroute other servers;
should not hub, unless hubbing is being tested by the Routing Department representative in conjuction with the testlink application;
o: lines are restricted to only those operators listed on the application;
Changes other than removal of an operator during the testlink are not permitted, without a majority approval from the Routing Department, the Zone representative, and notification to [email protected]

Testlink to Permlinked Servers
Upon approved testlink to permlink, the administrator and all operators listed on the application will become global O:, may be added to Sprint/OperOP/VoteOP, and are subject to O: line provisions within the Charter.

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 privilege, 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
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]

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]