Preamble:

An IRC network is an online area where people gather to chat.  The goal of any IRC Administration is to provide a safe place, where people can chat without fear of harassment, of any type.

Users Rights:

• to have a server maintained with fluid connections in the most workable configuration.
•  to have a trustworthy and capable staff to assist you with online needs as they apply to SorceryNet.
•  to provide sufficient services to users so that they can have ease of use and minimal interruption while on SorceryNet.

Administrative Level:

SorceryNet is founded on the principle that the network is governed by those people ultimately in charge of its servers. As individuals, the Admins have sole command over their servers. As a group, they have command over the network as a whole.  This control is delegated by the Admins, via this charter, to various administrative positions assigned to perform specific duties, tasks and functions.

Construction:

a) If an individual is assigned a specific task by this charter or the collective Admin, then that task may be delegated to another, unless it is strictly prohibited by this document, or by a majority vote of the Admin.

b) Altering this document requires a 'majority vote of the Admins' as defined in section 1.2. All provisions within this document have the authority equal to a vote of the Admin.

1. The Server Admins:

a) A Server Admin is the person recognized by SorceryNet Admin as being ultimately in charge of a server.

b) While an Admin can delegate any of their responsibilities, they retain the final say and are responsible for all actions as a result.

c) In the case of a server changing Admins, a vote of the Admin body is required to authorize the change.

d) In the case of an Admin changing or adding servers, a vote is only required if the server to be added is either less powerful than the original server or is in a different location net-wise. Any Admins may request a vote before the new server link if they feel either of these situations apply.

e) In the case of a server with multiple Admins:

• Each co-Admin has authority to exercise any power as if they were the sole Admin.
• In the case of a co-Admin disagreement, it is up to them to resolve disputes. If there is no resolution, the server is deemed to have no Admin, and must either be delinked or a new Admin must be appointed by a vote.

f) As a group, the Admin may counter any decision made by its staff. As individuals, they must follow the policies set by staff given the authority to set such policies.

1.1 Admin rights and responsibilities:

a) A server Admin may only call a CFV which he himself is not allowed to vote in when it regards negative changes to his server or adminship changes to his/her server.

a) An Admin has the right to call for a matter to be voted on by the Admins, irrespective of whether that Admin will be permitted to vote.

b) An Admin is responsible to vote on all matters in a timely manner. Failure may result in the loss of the right to vote in future votes.

c) An Admin has the right to appoint IRCops on their server, but other Admin may object and the appointment could be put to a vote.

d) An Admin is responsible for the actions of their IRCops and must ensure they are properly trained.

e) An Admin is responsible for keeping the SorceryNet Admin Team informed to any changes on his/her server.

f) An Admin must maintain the ircd configuration set by the network. This applies to running the correct version, code, and approved configuration.

g) An Admin must be subscribed to the 'admin', 'operations' and 'outage' mailing lists.

h) An Admin must adhere to the results of a vote of the Admins.

1.2 The 'Vote of the Admins':

a) If a vote of the Admins is called for, it is the responsibility of the Voting Managers.

b) A vote must be preceded by a CFD and it is to posted on appropriate lists as circumstances dictate. The CFD is called for a set time-period, with a minimum of one week, and a maximum of one month.

c) After the CFD is called, the person in charge of the process calls for a CFV, specifying who is eligible, and servers represented.

d) No server may have more than one vote. No Admin may have more than one vote.

e) If the matter being voted on is to server Admin change, delink or to force an Admin to comply with a task, no one listed as Admin on the server in question may vote.

f) Acceptable votes in are YES, NO, and ABS. Whomever requested the vote may disallow ABS votes.

g) The CFV lasts for 96 hours, divided in two equal blocks of 48 hours. At the start of the second block, anyone who has not voted yet is sent a personal reminder e-mail by the Vote Coordinators. The list of late voters is sent to the operations mailing list. NVC (No Vote Counted) is recorded after the second block ends and no vote has been received.

h) If more than 50% of eligible servers are listed as NVC, the motion fails. ABS votes are -not- counted as NVC. Otherwise, if the ratio of YES to NO votes is 2/3 or higher, the vote is passed.

i) If a motion placed for vote fails, it may not be re-voted unless the terms of the CFD is altered.

j) During each calendar year, a server is entitled to 3 NVCs. If this amount is exceeded, that server may not participate in any votes for the remainder of the year.

k) If a Server Admin will not be able to submit a vote, any Operator on that server should notify the Operations Coordinator during the CFD week, before the first CFV block starts. The vote will record as 'excused' and does not count as NVC under section j.

2. Network Director:

a) To oversee and coordinate the administrative structure of the network and provides direction and vision.

b) This said, the ND has no power to enforce their wishes or demands on the Admins or staff of the network. The authority is merely persuasive and it is expected that Coordinators consult with the Network Director but ultimately the decisions rest on the shoulders of those appointed to make them.

c) The ND will assist with Admin/Oper/user disputes as needed.

d) The ND must be a member of staff to be eligible to take this position. The individual must have held this position for at least one month.

2.1 Procedure - Network Director Confidence Votes:

a) Confidence Votes always start on February 1 and on August 1.  However, an Admin can call for a Confidence Vote at any time.

b) The Confidence Votes are initiated and coordinated by the Voting Managers.

c) Voting Managers must verify that each vote has been received separately. Opers must ensure that they have received a reply to their vote from both of the Voting Managers.  Otherwise, their vote could have been lost. At the end totals will be compared before releasing the results. Votes are sent to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it This e-mail address is being protected from spam bots, you need Java-Script enabled to view it.

d) A Confidence Vote lasts one week. Votes can be sent in starting when the Voting Managers or the Operations Coordinator announces the CV and when one week has passed the results will be posted.

e) All IRC Operators on Sorcery Net are eligible to vote, provided they have held an o:line on Sorcery Net for at least one month prior to the date of the CV. The Network Director is not allowed to vote in their Confidence Vote.

f) If 50% or more of the yes/no votes are in favor of electing a new Network Director, an election will start on the upcoming Monday.

g) If the outcome of a CV is that we do not need a new Network Director, a new call for CV may not be called until at least 2 months have passed from the closure of the previous Confidence Vote. The periodic Confidence Votes are not affected by this.

2.2 Procedure for the Election of the Network Director:

a) The elections are coordinated by the Voting Managers.

b) During the vote, all the Voting Managers must verify that each vote has been received separately. Opers must ensure that they have received a reply to their vote from both of the Voting Managers.  Otherwise, their vote could have been lost. At the end totals will be compared before releasing the results.  Votes are sent to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it This e-mail address is being protected from spam bots, you need Java-Script enabled to view it.

c) Anyone eligible to vote for the Network Director is also eligible to stand for the position. To be eligible to vote, one must have held an o:line on SorceryNet for at least one month prior to the commencing of the election process.

• Monday, on the first day of the election:  The election will be announced.
• Wednesday, first week: Those wishing to run for the position must have informed the Voting Managers of their intentions.
• Friday, first week: Those wishing to run for the position must have submitted a document to the Voting Managers outlining why they feel they should be voted into the position.
• Saturday, first week: These documents must be placed for public perusal on the SorceryNet webpages and mailing lists.
• Wednesday, second week: Voting starts. Votes are sent to the known Voting Managers address. Candidates for the position are not allowed to vote.
• Monday, third week: All eligible voters must have voted for their preferred candidate, or stated their wish to abstain from voting. The candidate with the most votes becomes the new Network Director.
• Wednesday, third week. The result of the vote is announced by the Voting Managers.

d) Failure to nominate or submit a platform document by the required day disqualifies a candidate from running.

e) If there is only one candidate at any time after the close of nominations, that candidate is declared Network Director by default.

f) If at any time after the close of nominations there is no candidate, the election is canceled. The network runs without a Network Director and each month the election process is repeated until a Network Director is found.

3. Positions:

Once appointed, the Network Director appoints 3 Coordinators that are responsible for the day-to-day running of the network. Once appointed, the Coordinator has a 30 day probation during which he or she can be removed by the Network Director without needing a vote. After probation, removal of a Coordinator requires a vote of the Admins.

Individual Coordinators are allowed to appoint staff but remain accountable for the key area and have responsibility for the conduct of their staff. Their decisions are binding and can only be overruled by a vote of the Admins. It is a requirement that all Coordinator positions are held by different individuals.

These are the 3 Coordinator positions:

1) Operations Coordinator

Oversees the development & User Services Coordinators.

2) Development Coordinator

Maintains the legacy sorservices codebase and the SorceryNet specific Charybdis & Atheme extension modules. Liaises with atheme.org upstream developers.

3) User Services Coordinator

Maintains any network infrastructure that is not under the direct control of an individual Admin, such as the website and e-mail. Also responsible for user facing services such as the #help and #sorcery channels and any maintenance of K-lines based on This e-mail address is being protected from spam bots, you need JavaScript enabled to view it feedback. Responsible for the configuration of the services binary and as such, for the appointment of Services Root Admins.

4. IRC Operators:

a) IRC Operators are appointed by Server Admin.

b) The Operations Coordinator is responsible for maintaining a list of all current IRCops.

c) The Postmaster is responsible for ensuring each IRCop has a mail alias of the form This e-mail address is being protected from spam bots, you need JavaScript enabled to view it This e-mail address is being protected from spam-bots so you need Java-Script enabled to view it.  Where 'nick' is, the nick by which the oper is listed in the MOTD of their primary server is placed.

d) Each IRCop has a single primary O:line. The Admin of the IRCops's primary server is responsible for the IRCop. Any Admin may give an IRCop a 'backup' O:line on the Admin's server if it is desired. If an IRCop loses his/her O:line on the primary server and no other server wishes to grant him/her a primary O:line, all backup O:lines must be removed.

4.1 IRCop Duties and Responsibilities:

a) An IRCop is responsible for everything his/her nick does while opered; including a terminal left unattended, even if someone else uses their account.

b) An IRCop has a primary nick which is listed in MOTDs and mail aliases. This nick must not be allowed to expire.

c) An IRCop must vote in the Network Director elections if eligible.

d) Oper misconduct is dealt with first by the relevant Admin, then the Network Director if there is no resolution and finally by the Admins as a group.

e) An IRCop must be subscribed to the 'ops' and 'outage' mailing lists.

5. Linking and Delinking Servers.

5.1 Applying Servers.

a) Linking or delinking a server permanently to the network requires a vote of the Admins, with the CFD held on the public mailing list.  Linking a server requires a 2/3 majority in favor of the application.

b) The Admin of the new server has no access to the This e-mail address is being protected from spam bots, you need JavaScript enabled to view it mail list during the probation period. Only when the probation is over will the new Admin get subscribed to it.

c) A test link of an applying server is mandatory and will be made during the CFD period. It is the prospective Admin's responsibility to ensure that the server is test linked. Only current SorceryNet IRC Operators are permitted to have global O-lines on a test linked server. The prospective Admin and his/her Opers may only have a local o:line during the test link. Prior to the server being test linked, the ircd.conf must be submitted to a current   Application Manager to be checked for discrepancies. A test linked server will be linked with the following naming scheme:  Servername.test.sorcery.net.

d) After a server gets a positive CFV result, the server gets a one month probationary link. During this period, the Server Admin has no voting rights in CFVs. When the month has passed, the Server Admin gets voting rights by default, but any Admin may call a second CFV.

5.2 Code Testing Servers.

a) The Development Coordinator or the IRCd Development Manager may temporarily link a server for the purpose of testing changes to SorceryNet related code or new SorceryNet related code at any time.

b) An announcement should be made to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it no less than one hour before the link occurs. This is to make sure that everyone knows the purpose of the linked server.

c) The coding server should be linked with either servername.code.sorcery.net or servername.test.sorcery.net as a naming scheme.

5.3 Emergency Servers/Situations.

a) A server may be linked, juped or delinked in an emergency situation by anyone who has the technical power to do so. The person who will be performing this operation should seek as much comment from Admins and Coordinators as they can, taking into account the nature and degree of the emergency.  Misuse of these powers constitutes serious misconduct against the network.

b) Any emergency linking or delinking should be announced to the outage mailing list and may be rejected by the Admins. Any emergency linking or delinking that is for an extended period should be accompanied by the immediate commencement of an Admin vote to approve it.

5.4 Technical:

a) SorceryNet IRC servers are required to have TCP ports 6667, 7000 & 9000 open to the world, with no filtering or rate limiting in place. TCP port 9090 is required to be available inbound for server-to-server links, which is recommended to be firewalled to only accept connections from other servers in the network.

b) The Charybdis IRCd is used. Use of GNU/Linux with a 2.6 kernel is recommended, but other POSIX-compliant operating systems can be used. A stable time base is required to maintain stable IRC links. As such, the use of an NTP server is mandatory. Operating systems in a virtual machine will be at a disadvantage here and proof of a stable timebase will be requested for such configurations.

c) For maximum resilience, any server in the pool should be able to hold the full client count. At the time of writing, this means your machine should support a minimum of 1000 concurrent clients. The machine that you apply with should have a minimum of 256MB RAM and is expected not to run other high-bandwidth tasks (such as an IRC daemon for a competing network or a high traffic rsync mirror).

d) The Server Administrator is expected to be comfortable with compiling software on his/her operating system. At your option, either a 24/7 contact phone number or a second person with shell access to the machine should be available.

6. Acceptable Use Policy.

a) A Server Admin may restrict any behavior they wish from their server. Any server-specific regulations should be listed in the MOTD.

b) Cloning, flooding, harassment of other users, and abuse of a server or services is prohibited.

c) This network will assist any and all law enforcement agencies investigating illegal activities on this network.

d) The Server Admins reserve the right to discontinue service to any user or group of users for any reason, and without notice.