J-Body IRC Charter
Version 1.0
Drafted February 24, 2002

1. J-Body IRC Objective
   a. The main objective of J-Body IRC (hereafter called "the network") is to provide a network where people can talk with each other and enjoy themselves. In order to facilitate this, all clients connecting to the network must adhere to the Acceptable Use Policy.
   
   b. On the network, channels are owned by users. Contrary to the policy of other nets, the current op-holder, whoever he or she might be, does NOT necessarily own the channel. the network has a service called ChanServ, with which a user can use to register a channel and assign ops and super-ops, as well as perform various other functions relating to channel security.  Channel disputes--when one party believes that the current channel owner isn't running the channel properly, or whatever--will be mediated by one or more IRC Operators or Administrators at the request of the users of the channel.
   
   

2. J-Body IRC Operator Responsibilities
   a. The responsibility of the network IRC Operators (IRCops) is to provide for a safe and fun environment in which to chat. This means if a user requests an IRCop's assistance, that IRCop must investigate and take any action necessary into that user's situation. If the IRCop is otherwise indisposed, however, he/she must say so in their /away message, so that the user will know to look elsewhere for assistance.
   
   b. IRCops must use their judgment on when to use /kill or other means of enforcing item #1 above. If the battle is 'personal', however, /kill may not be used. J-Body IRC Administration will support any IRCop's decision to use /kill if the situation appears to have warranted it.  Example: JoeUser is sitting innocently on a channel when EvilUser floods JoeUser. JoeUser tells IrcOpJon that EvilUser is flooding him; IrcOpJon /kill's EvilUser. If EvilUser complains to another IrcOp, IrcOpJon's opinion--that JoeUser said EvilUser was flooding--is held above EvilUser's, with JoeUser's testimony to back him up.  It is understood that this has a potential for abuse--we will investigate incidents where a single user is being flooded by people who don't flood anyone else, or something like that. It's not easy to be completely fair, but hopefully this will help.
   
   

3. J-Body IRC Server Administrator Rights and Responsibilities
   a. The responsibilities of a the network Admin include, but are not limited to:
       (1) All responsibilities granted to IRCops
       (2) Upkeep of his or her server's software, and upgrade of the software to the current the network version within a reasonable time after the version's release.
       (3) Keeping the server's configuration updated and consistent with the network practices.
       (4) Keeping him- or herself up-to-date in the network policies, procedures, and activities.
       (5) Voting in the majority of official Administrative CFV's (calls for vote).
       (6) Keeping the network administration as a whole aware of any prolonged absences.
       (7) Appointing a representative to fulfill his or her duties when necessary, and informing the the network administration as a whole of the appointment.
       (8) Informing the the network administration as a whole of any changes in a timely fashion.
       (9) Appointing or removing IRCops he or she trusts to act in the best interests of his or her server, and of the network as a whole
       (10) Upgrading 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.
       (11) 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 comparable capability, and the server's location does not change.
       (12) 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.  This includes, where possible, advance notification to the Server Administrator's Board of scheduled downtime or changes to server configuration.
   
   b. A Server Administrator does not have the right to:
       (1) Move his or her server, net-wise or physically, to a location generally regarded as inferior, except as a temporary or emergency measure, as decided by the Server Administrator's Board.
       (2) Drastically alter the location of the server net-wise or physically.
       (3) Link a server which has not been officially accepted by the the network administration except in emergency situations with the approval of an Administrative vote.
       (4) Have more than one vote, even if he or she runs more than one server, or co-Admins a server, unless more than one vote is granted by a CFV.
   
   c. Delinking a the network server
       (1) The following are reasons for possible removal of a server from the the network network:
           (a) If a server is not connected more than 50% of a 30 day period.
           (b) If a server has no vote in 5 or more of the last 7 CFV's called by the the network administration
           (c) Failure to update the ircd files or configuration in a timely manner.
           (d) If the admin loses access to the server, and its files.
           (e) The admin(s) of the server abandon it.
   
       (2) A CFV should be called by the Server Administrator's Board within 5 days of notification by an Admin, that one of the above conditions have been met. The CFV should include what should happen if the server is not removed, including voting rights of the admin. If the Administration votes in favor of delinking, all the network servers shall remove the links at earliest convience. If the Administration votes against the removal of the server:
           (a) Any actions stated by the CFV are to be put in effect immediately.
           (b) The server should then have a probationary period of 60 days of closure of the CFV, or from when it returns to the the network network.
           (c) At the end of the probationary period, another CFV can be requested if another admin feels the server/admin did not fulfill the duties neccessary of a the network server and admin.
   
       (3) A server may be temporarily de-linked (juped) if it shows considerable disruption the the rest of the network. This action should be no longer than 5 days. Otherwise, it qualifies for de-link (Failure to update the ircd files in a timely manner.)
   
   d. RE-CFV's AND ACTIONS TAKEN DURING EMERGENCY SITUATIONS  A re-CFV may be called on a server if requested by an Admin, to approve emergency measures taken by an Admin if those measures are outside the rights granted to an Admin and have been in place for more than two weeks, and MUST be called on a server if that server remains down for longer than 45 days or has been delinked by a CFV. 'Emergency measures' may be taken by a non-Admin if the measures are approved by the CEO or the CEO's appointed representative. Emergency measures may be in place for the period of one month without a CFV.
   
   e. Emergency Situations  An 'emergency situation' is a situation, as agreed upon by a minimum of 2/3 of the network's Server Administrators.
   
   

4. Technical requirements of servers
       a. Each server must be the agreed-upon version used by the network.
       b. Its machine must have a relatively system load that will allow for the server. The machine must be stable enough to support the server 24 hours a day, and the link to the Internet must be at least T1 for a server, or Multiple T1 for a Primary hub connection.
   
   

5. Policy decisions
       a. Policy decisions include, but are not limited to:
           (1) Making changes to the charter
           (2) Adding/removing servers
           (3) Voting to bring action against an admin or IRCop.
       b. Votes are to be called by the network's Server Administrator's Board (The current board, at the time of this writing is the network's founders DaveDotOrg, JimmyZ and Scrufdog) or by a person (or persons) appointed to do so by the board.  A single vote is allocated to each of the board members, and administrators of all current servers. It is the job of the IRCops of each server to convince their Admin to vote one way or the other. An issue will be "passed" if 2/3 or greater of those eligible to vote, vote "Yes". An issue will be "rejected" if 2/3 or greater of those eligible to vote, vote "No". If neither of the previous instances occur, the vote will be "pushed" and revoted upon. It is the duty of each Admin to either cast a vote or appoint someone to cast a vote for them.
   
   

6. Disciplinary action
   a. If an IRCop, Admin or server repeatedly fail to meet their requirements, as defined in #2, #3, and #4 above, a review will be held in order to re-evaluate that person/server. The voting will be the same, except that the person/server who is being evaluated will not be allowed to participate in the voting process. If it is decided that the person being evaluated should be removed from his/her position, the following actions should be taken:
       (1) If the person is an IRCop, their Admin must comply and remove that person's O:line.
       (2) If that person is an Administrator , or if a server is voted to be delinked, the links to that server will be removed and the server taken off of the network.