textfiles/bbs/FIDONET/policy.110

/\
\
 \ 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.