 | |
Welcome to Hybnet.ca! |
|
|
Index
|
HYBNET RULES & POLICIES Revised by: Stephen Olsen date: 20 June 2001 § 1. Users §1.0 When a user connect his/her client to any server linked to the Hybnet IRC network, the user agrees to the follow by the local servers rules and policies in addition to the following network policies. §1.01 Not to spam, send mass messages to to people who are unknown to the user or do not wish to receive messages, in order to publicize something which you profit of. §1.02 Loading multiple clients, clones or drones, to the network. Doing this is grounds for a network wide ban. §1.03 As we run channel/nick services on this network, bots are not needed, and are forbidden on most servers, however is you find it necessary to run a bot for you channel, use a server which allows them, there are always some. §1.04 For assistance regarding nick and channel services /msg nickserv help or /msg chanserv help . If the help is inadequate contact one of the core members.
§ 2. Operators §2.0 When you /oper you are agreeing to follow your servers rules and policies in addition to the network rules regarding opers. §2.01 The official kill policy on this network: Kills may not be used if your angry or just don't agree with someone. The only thing you should ever have to kill are drones, bots, or spammer, however klines and glines are strongly recommended for this. If you have to kill someone, make sure it is not another oper. Global killing a friend to congratulate or for testing purposes can be accepted if it occurs in a controlled manner. Vanity kills (global kills, that are unnecessary, or multiple global kills) are forbidden. If vanity kills are registered multiple times, and the server admin has not done anything, the network (other admins/core members) may require the opers O-lines to be restricted to local, or removed completely. §2.02 An oper is appointed to represent the sever and the network, by serving the network. If proven that the oper is abusing their power this is ground for oper removal. An oper will monitor activities around the network and try to prevent abuse. Opers will give assistance with the services and irc questions, and also help in maintaining the network and its users. §2.03 Opers will not KLINE or GLINE users without any specific reasons. If this happens, the admins will look into it and take necessary action to prevent this from happening in the future. Opers will not interfere in channel registration and nickname registration. The registration is based on first come first serve basis.
§ 3. Administrators/Servers §3.0 The admin is required to set up his/her own server rules and policies for all users which use the service provided to abide by in according to network wide rules and policies. §3.01 Each admin is required to make sure his/her server meets the following requirements at all times. §3.01.1 Run a Hybrid ircd §3.01.2 Any modifications made to the source of the official hybrid ircd, need to me notified to core and approved before it is allowed to be used on the network. §3.01.3 List an admin contact in the A: line (preferably the server location as well) §3.02 Has to be able to make necessary changes to the configuration of the server within 48 hours, unless the admin list has been notified before hand. It is desired that a second person has access to the config in the absence of the primary admin. §3.03 Before a new oper is added, at least 1 day before the addition, the hybnet admin list should be notified with the opers nick, real name and location. (This may benefit, if one of the other admins has some new information regarding the oper which should be known. §3.03.1 Every new oper should at least have a one week trial with a small o: , even if the person has been a global oper on another server. A new oper may only receive a big O: if the oper is a server admin of another hybnet linked server. §3.04 If a server admin has packeted any users/servers on any network , the server may immediately be removed, unless the claims of the packeting can be disproved. §3.05 Servers that are not used for routing purposes and have over a longer period of time, has had less than 5 active users, may be removed after efforts to get the admin to improve the situation have failed.
§3.06 Admin duties: - Dealing with the software of the IRC Network such as upgrading. - Dealing with the policies and the rules of the IRC Network. - Taking responsibilities of all the appointed IRC Operators. - Informing all the administrators about any changes for his/her IRC server. - Admins do not interfere with the conflict in channel registration and nickname registration. The registration is based on a first come first serve basis. - Admins will not KLINE or GLINE users without any specific reasons. - Admins are responsible for keeping their c/N lines up to date. Any changes requested by routing should be completed within 7 days. If a server fails to have a live admin then it may be considered for delinking. - If a server does not have enough live opers it should at least run some kind of TCM bot. - Servers should decide and enforce local kill/kline policies.
§ 4 Core (routing) members / hub-admins §4.0 Core members consist of global representation (mostly hubadmins, in addition to a couple normal serveradmins). The current core members. §4.01 Core acts as the governing act of the hybrid network. Its duty is to take care of various regulations, granting trials to new severs, making sure network rules are followed. §4.02 If there are multiple complaints about a core member, these can be voiced in the admin list and then the matter will be decided on by core, and investigation of the member will take place. §4.03 Each core member has OperServ access and can be contacted if there are any nick/channel problems regarding services. §4.03.1 The following rules need to be abided by regarding OperServ: - Only current core members will have access to OperServ. - Jupes are a last resort - any jupes should have an explanation for its reason and notification posted to core/admin mailing list with logs if necessary.
§ 5 New server process/policies §5.0 Every new server has to fill in the application located at http://www.hybnet.net/serverapp.html any other server application form is unofficial and must not be used. When the application form is received on the hybnet admins list, admins etc. can comment on the application. The secretary will call a vote in core. §5.01 A server that applies and has an admin or oper which has a reputation of being a packet/script kiddie, will be rejected, as hybnet does not want to be associated with this kind of activity or reputation. The applicant will be notified by the secretary. §5.02 If the server application does not include the required information correct/detailed location, hardware, software/OS or traceroutes, the application will be rejected and the applicant notified by the secretary. §5.03 When the secretary announces the results regarding the vote on granting a trial link, only then will the applicant be able to receive c/N lines from hubadmins. And the applicant will be notified by the secretary. §5.04 The trial will last a minimum of two weeks, a longer trial is often given to be able to get a better understanding/picture of the server. The secretary will after the trial is over, call a vote to grant permanent status for the server, only if the trial regulations/requirements have been met. §5.04.1 The requirements of trial servers are as following: - A minimum userbase/average of 10 users - Official hybrid ircd - local kill only - Available admins/opers §5.04.2 After a perm vote is called by the secretary all server admins are to vote. The vote will last a week, or if all vote are in before. The results will be announced by the secretary. §5.05 When the server gets a trial the server has to have the equivalent of local kill only, small o-lines, throughout the duration of the trial. Trial servers are limited to 3 opers including admins.
§6 Services §6.0 To avoid useless waste of bandwidth for bots to preserve channels and nicknames, this irc network runs services. §6.01 Channel Registration Hybnet provides the users with channel registration. The users will register the channels and ChanServ will protect the channel. Protected being that the channel is managed without bots. If the channel is not being attended by anyone within 22 days, the channel may be dropped. If a channel has been registered but is clearly not in use, we reserve the right to drop the registration for that channel so that others may use it. This will only be done after some research. §6.02 Nickname Registration Hybnet provides the users with protection of their nicknames. They can register their nickname and decide to not let anyone use it. If the nickname is not used within the certain time set by the Hybnet Core committee, the nickname will be dropped and it is available for anyone who wants to register it. Nicknames are important on Hybnet. Most functions require your nickname for identification, although you can use your hostmask for the authentication. §6.03 We have the right to deny certain nicknames and channels. We also have the right to jupe any nickname or channel that is being used abusively. §6.04 At NO time, for any reason shall an admin/oper /kill any of the services clients ie. Services, NickServ, ChanServ or OperServ. Doing so is grounds for instant removal of the server the admin/oper is serving on. You will also not use the nicks Services, ChanServ, NickServ or OperServ at any time.
§7 Abuse §7.0 Actions that are regarded as abuse will be dealt with primarily by core. §7.01 If there is a complaint about an oper for any reason it should be taken to is/her server admin. Such examples of abuse may include killing for a ban, excessive global kills, etc. §7.02 If this person is the admin of the server then the issue should be brought to core, which will decide on what actions will be taken.
§8 Voting §8.0 On all votes, a majority is reached when more than 51% vote yes or no. §8.01 On hybnet-admins votes all servers are requested to vote. However if an admin of a server also admins another server, only one vote can be given on behalf of both the two servers. §8.02 If a server abstains then it will not be included in the vote count. For example, 5 servers vote yes, 3 servers vote no, and 4 servers do not vote, then the vote will be counted from the 8 voters, and in this case yes would win the vote. §8.03 If a yes or no majority is reached before the voting period is over the secretary can optionally call the vote off by announcing the results. But in no case shall any other party announce the vote. If there is any other announcement from another party then it is not valid. The only time this is not the case if the secretary appoints somebody to take care of the vote, but this would be notified to the voters by the secretary. §8.04 All votes within core are similar, however the voting periods are not applicable. Every member in core is able to vote regardless of servers they oper/admin. |