/\ \ \ YNDICATE-NET - (C) copyright 1993 -- Todd Alan Rourke \/ Official Statement of Policy - Revision 1.10 By Todd Rourke, Al Miller and Raymond DeRoo Syndicate-Net is a network dedicated to one primary end, along two somewhat divergent paths. This end is to attain a fluid and fruitful exchange of knowledge between users from various bulletin board systems. On the one hand, this end is to be reached by the exchange of technical information from computer hardware/software enthusiasts. On the other hand, the end will be reached via several philosophical and 'debate' echoes designed to cater more to the rhetorical than to the technical. In both cases, conversation is expected to be relevant, topical, and intelligent. If you are looking for a 'general chat' network, this is NOT the place for you. This network seeks to be taken seriously, and to that end, only the serious-minded should consider a link to Syndicate-Net. The stimulation factor is expected to be high, and the quality of the information being exchanged is also expected to be kept at a high level. No drivel; no nonsense; just the minds at work postulating great ideas on everything from the BEST ways to configure a certain utility to just WHAT the Book of Leviticus really means to the Christian faith. Just what is ordained as an 'intelligent' or otherwise 'quality' message? There are no strict rules on this, each and everyone of the users of Syndicate-Net will have to rely upon their best judgement. In line with the intent of the network, we are expecting all links to limit access to users who the SysOp -knows- is capable of a rational interchange of ideas with other rational people. Everyone is allowed in at first, but a user of the network is obviously being a cretin, he WILL be asked to leave. This is harsh, yes, but the fact of the matter here is that the 'Gods' of Syndicate-Net are not putting this network together for idle 'fun time'. We are all members of other networks that cater to this role quite nicely (and will happily refer you to one of these if that is what you are looking for). We -did- see a gap in the realm of a serious-minded EchoMail network where the 'fun' would be the sheer fact of engaging with other intelligent souls from all sorts of locations. A veritable (and literal) meeting-of-the-minds and 'network think-tank' of the highest order. The primary directives of Syndicate-Net are simple and easy to understand. We expect all parties to read and obey. If you cannot see yourself following these basic guidelines to the letter, we honestly suggest you look for another EchoMail network to participate in. We are not here to be tyrants, but we are not here to baby sit, either. 1) Be friendly and courteous to each other. This is a really hard area to legislate. Let common sense be your guide. We realize that some ECHOEs in the network may allow more aggressive discussions. As a rule of thumb, if you wouldn't want someone to say it to you... don't you say it to them. 2) Handles are allowed as long as each user has only one handle. The Sysop of each system is responsible for *ALL* of their users and can therefore allow or disallow handles on his/her system. Any user found using more than one handle on the network will be given a warning. A second infraction will result in that users loss of access to the network. Should a third infraction occur the system from which the message originated will be dropped from the network. 3) Using a handle of another user is strictly forbidden. The network can REGISTER your handle in which case no other user in the network may use you handle. In a dispute over handles the user that registered 1st is the winner. Registering a handle is nothing more then sending a message using your handle to REGISTER in the SYN_GLOBAL echo. You are *NOT* required to register your real name but we would appreciate it. The loser in the handle dispute must then choose a new handle for use within the network. This applies to handles ONLY. Real names cannot be expected to be changed for network rules. NOTE: The registered handle becomes associated with the SYSTEM it was registered from unless the user leaves his/her real name. 4) Intentionally disrupting the flow of mail through the network by sending many worthless messages or any other means is strictly forbidden. Infractions against this rule WILL be dealt with harshly. Users in violation will be removed from the network. Failing this, the entire network link to the system where it is originating from will be cut. 5) Illegal and obscene activity of any kind is not allowed. Moderators will generally police this sort of activity in their echoes... and ask all illegal activity to be quelled. Any node found purveying said is subject to an automatic drop from the network without a hearing and without an inquiry. 6) Mail that is sent as private though this network is *NOT* guaranteed to be private. As with U.S. mail the content of mail in this network becomes the property of the RECEIVER. The moral of the story is: if you send someone PRIVATE mail they can post it publicly anywhere. It *IS* allowable to use PGP (or the like) utilities to encrypt mail if you so desire, this applies only with routed NETMAIL, however. 7) Participants in any given echo are expected to follow the rules of said echo as posted by that particular echoes moderator. Moderators are expected to post their echoes 'rules document' somewhat frequently. Once a month would be recommended in most cases we can for see. 8) Every system on the network is REQUIRED to carry ALL of the administrative ECHOEs. These ECHOEs are considered necessary to the successfully running of the network. The required ECHOEs are: o SYN_SYSOP - General network announcements are made here including policy changes, announcements, and discussions. This echo is for SYSOPS members only. o SYN_GLOBAL - Network wide ECHO to be used for registering handles, and requesting disputes to be resolved. Everyone should have access to this echo. 9) Sysops are 100% responsible for the users on their board. If a user on your system does not follow the rules you will be notified by NETMAIL. If you don't correct the problem in a reasonable time your access may be temporarily restricted. Should such action continue to persist, then removal from the network will follow. 10) Nodes must be on-line at least during network mail hour. Network mail hour is defined to be from 4am ET to 5am ET. HOSTs are expected to monitor this and make sure nodes are up for mail at this time. Any node NOT operating in ZMH can be removed from the nodelist by the HOST with the prior OK of the area REGIONAL. 11) Jury duty is required of all sysops in this network. When a policy dispute is initiated 5 sysops will listen to netmail testimony and reach a verdict. Jury selection will be on a rotating basis, we will start at the TOP of the nodelist and work down. As in a court of law the Judge (ZC) can overturn any jury decision. (THIS WILL BE FROWNED UPON!) SysOps selected must have been in the network for either SIX (6) months or be at least of HUB, HOST or REGIONAL status. a. Formal Initiation of Dispute - Attempt remedy at the node/host level with carbons of all mail going to regional. If this fails, direct intervention of the regional into the matter with carbons being forwarded to zone coordinator. If this fails, ZC informs the council to begin deliberation and opening arguments are heard from each side. The process -can- be requested at any point by either the involved host, node or regional. If the request route is used, however, the ZC can decline to hear the case until all previously mentioned avenues are used and fail. 12) HUBs need to be in operation 24hrs/day 7 days a week, supporting CrashMail during these same hours. Hubs are also expected to pack mail for distribution to their NODES at least TWICE per day. These packs are to be no more than 12 hours apart. 13) HUBs need to provide ALL requested ECHOEs to nodes that underneath them. If the demands on a HUB become unreasonable then the HUB may either implement a cost recover system, step down, or appeal to the network for a policy-decision. In general, cost-sharing should be dictated by the HUBs local Network Coordinator. 14) HUBS are required to carry the SYN_HUB echo which will contain hub related announcements. They are also required to make all nodelist updates, newsletters, etc. readily available to their links. This can be by FREQ or (preferably) some automated file distribution system. 15) HUBS are *REQUIRED* to route netmail for systems under them. HUBS are NOT required to PAY the bill for routed netmail. If a system abuses a HUB the sysop of the HUB may file a policy complaint. 16) The HOST system will process applications for this network in a reasonable time frame. Reasonable here is left to the discretion of involved parties, but as a matter of practice, 2 weeks should be allowed for processing a new node. 17) HOSTS distribute the nodelist to all nodes immediately underneath them. This may be done in a number of ways, including TICKing files and/or having said files available for 24hr/day FREQing. It is again the responsibility of the area RC to enforce this rule. 18) HOSTS attempt to settle local disputes prior to them making it onto the REGIONALS desk for a decision, or before it moves into SYN_GLOBAL for a Jury verdict. 19) HOSTS distribute the network newsletter to all nodes underneath them. The newsletter will be published semi-monthly at first and as the network grows will may be published more frequently. 20) REGIONALS are the primary administrative link for a given area. All network matters within a given region will be handled by the Regional Coordinator for said area. This includes disputes, network links, polling coordination, and other facets of the network that effect a given region as a whole. 21) REGIONALS are generally expected to be the PRIMARY point of entry of EchoMail into the given region. Topologically speaking, the Regionals would poll Backbone (main Syndicate-Net system) and then provide mail load to the nets under them for polling. Each net should also have ONE primary EchoMail hauler, and this is within the dominion of the Regional to select the primary hauler for each net under the Regional. 22) REGIONALS are expected (and ultimately REQUIRED) to have nodelist updates, newsletter, and ALL echo areas available to all nets under them. Methods by which these are made available are the same as those covered under HUBS. Except that they are required to have the latest nodelist and information pack available for FREQing. 23) MODERATORS are the primary force behind this or any other EchoMail network. A good moderator can make an echo area a true joy, a bad one can make it a mish-mash of nonsense and idiocy. Moderators have the duty of patrolling their given echo(es) to police post content. Moderators must keep user discussion topical to the area in which the conversation occurs! 24) MODERATORS may create (and are encouraged to create) a set of rules for their echo. These rules may ADD TO but not DELETE FROM this binding policy file of Syndicate-Net. 25) MODERATORS may create their own system for reprimand and punishment for abusive or constantly off-topic users, but it is suggested that a policy of 'Three strikes, you're out' is attempted to be adhered to. In any case, the methods of reprimand should be CLEARLY defined in each Moderator's rule document. Those are the primary 25 points of 'policy' for Syndicate-Net. They are by no means completely comprehensive because this network is intended to be run as a pseudo representative republic. These are but the basic tenets to abide by. Actual day to day policy of the network is covered in the following text, which concerns the empowerment of various figures in the network. BACKBONE - Primary system of the network. Final say in ALL network matters. It is NOT expected that BACKBONE will have to make many decisions in the realm of the day-to-day operations of the network. Only the most SERIOUS issues will be heard by BACKBONE. REGIONAL - The 'effective' backbone for a series of nets under it. REGIONAL is expected to try to settle all disputes within it's area without bothering Backbone about it. In general, the day-to-day operation of the network is not a prime issue here, but the REGIONAL is expected to be closer to it than Backbone is. HOST - This is the 'Net Coordinator' of a given net in Syndicate-Net. The HOST answers directly to its REGIONAL. HOSTS are the primary 'day-to-day' policy makers of the network. It is hoped that most disputes will be handled on the HOST level. HUB - HUBs carry no official administrative capacity. A HUB answers to its HOST and is expected to obey what its HOST decrees. HUBS distribute mail, and MAY play a role in a net-policy if the HOST allows. This is by choice of the HOST only. Official Regional and Backbone stand is that the HUB is to provide mail to nodes, nothing more. NODE - End system of the chain. Receives mail from its HUB, but falls under the doctrine of its HOST. The settlement of disputes in an individual NET or REGION is expected to be handled in a timely and mature manner. Essentially, the HOST has the authority to cut feeds to any node in his net that is disobeying net policy. A HOST is also expected to execute orders to cut-links on the order of its REGIONAL or from a mandate from BACKBONE. Moderators seeking to have links cut to a system must first approach that Nodes REGIONAL. If the link cut is just for a specific user, then the approach must be to the SYSOP of the NODE from which the user hails. In most cases, the HOST is allowed to run his network as he sees fit, as long as he remains within the context of this document. In certain cases, after review of the REGIONAL, an issue may be decided to be important enough to be ruled upon and for the ruling to be adopted into the POLICY of the network. In this case, the 'jury duty' mentioned previously comes into effect. BACKBONE will handle the selection of the jury, and the affected HOST(s) and NODE(s) will present their case. Generally speaking, the courtroom will NOT be a forum for over-ruling a Moderators decision to cut a user or a node. The courtroom will be relegated to handling personal/network conflicts between nodes and nets (and regions if need be). Generally POLICY is what is the key issue to whether a dispute makes it to the courtroom. Backbone will hear all sides and ask for opinions from the Regionals, and then leave a verdict up to the jury. The decision will then be reviewed by Backbone and amended to POLICY as needed.