280 lines
16 KiB
Plaintext
280 lines
16 KiB
Plaintext
|
|
/\
|
|
\
|
|
\ 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.
|