Difference between revisions of "CommunityAdministrationNetwork/Field Agent"
m (CommunityAdminstrationNetwork/Field Agent moved to CommunityAdministrationNetwork/Field Agent: Misspelled "administration")
|Line 2:||Line 2:|
This page describes the information needed by Field Agents for the [[
This page describes the information needed by Field Agents for the [[/About|Community Administration Network]].
Latest revision as of 20:42, 4 November 2007
- 1 Overview
- 2 Requirements
- 3 Behavior
- 4 Administrative actions
This page describes the information needed by Field Agents for the Community Administration Network.
Field Agents must meet the following requirements.
Field Agents must have a valid global name and login, with valid contact info.
Field Agents must be at least 17 years of age, or be approved by the network administrator. Field Agents must report their correct age to the administration staff when asked.
Field Agents must have a clean record on the master ban list, and not have any outstanding bans or issues on any CAN servers.
Sponsorship and approval
Field Agents must be sponsored by at least one Core Administrator. 3 Field Agents can petition a Core Administrator to sponsor a new Field Agent. All new field agents must be approved by the Core Administrators, or the Network Administrator.
Field Agents are expected to follow a behavior guideline when playing on CAN member servers.
Follow the Rules
Field Agents are expected to follow the same rules as players when playing. Violations of these rules will lead to removal from the administration staff, as well as possible network administrative actions ( bans ).
Field Agents are expected to conduct their administration in a calm and civil manner. They should not let anger or personal feelings get in the way of their administration duties. They are expected to not hold any "grudges" against specific users. All discussions, arguments, or disagreements with players over administrative issues should happen in private in order to disrupt the play for others as little as possible. Field Agents must remember that it is their job to help all users play the game and have fun.
Give the benefit of the doubt
Field Agents are expected to give a user the benefit of the doubt when dealing with an initial violation. Users should always be approached with private chat text to ask them first to stop the behavior that is causing the violation. The agent should explain what the behavior is, why it is a violation, and be willing to help the user resolve the issue to the best of their ability. Field Agents are expected to remove bans on users who have spoken with them or other administration staff in a civil manner and have agreed to not repeat their offenses. Users that abuse this will not be given that courtesy a second time.
Use the least necessary action to resolve an issue
Field Agents are expected to resolve issues with the "lowest" possible administrative action. They should not kick when a silence should work, not ban when a kick would do the same. Bans should be the last resort as they are network wide. Field Agents are expected to warn before all actions. The CANAdmin plug-in will track and enforce the warning of people before higher level actions are allowed ( kick and ban ). Field Agents are expected to work with all users to resolve any violation issues, and never simply "blow them off". They should refer the user to the Core Administrators if a suitable resolution can not be found.
Use CAN admin abilities only for network violations
All admin actions on servers must be in response to a violation of one of the six network rules. No other use of the network admin functions are permitted. The CANAdmin plug-in will require the rule number that is in violation for all actions. Field Agents may be granted additional abilities by server owners, and be asked to enforce additional rules. If the Field administrator agrees to this, then he/she must use the server's local administration system to enforce those additional rules, and not the network system.
Violations of rule 5, the minimum language rules, must violate the very specific conditions set forth in the rule. Interpretations of the rule should strictly adhere to the rule as stated. Flexible interpretations based on additional language that is not mentioned in the rule, personal distaste, or beliefs, are not allowed. Violations of rule 5 must be very clear-cut before ban level action is taken. Most users who will skirt the edges of rule 5 will most likely break another rule in the process, usually rule 4. Simple violations of rule 5 can be handled with a simple net silence command after the required warnings. While annoying, violations of rule 5 have the least affect on the game, and are the simplest to resolve, even for regular users ( everyone can use the silence command ). Field Agents are expected to understand that different people have different levels of tolerance for language, and may find things more or less offensive then they personally do. Common saying that may have religious overtones, are not considered offensive. Attacks must be very directed against very specific subjects. Terms or abbreviations like "OMG", "WTF", and the like, are common enough in language that they are not meant as offensive they are simply exclamations. Any action that is simply taken as "blasphemy" in any religion is not worthy of action and should be ignored, unless the player uses the text in a violation of rule 4 (spamming).
Agents that abuse the network admin features for their own personal reasons, will be removed as network agents, and possibly banned from the network depending on the severity of the actions. All network actions are logged with the BZID of the admin who applied them. If need be the Core Administrators can remove any and all network actions caused by any Agent.
Field Agents may take the following administrative actions on any member server. All actions are logged and recorded with the administrator that performed the action, and the server that they were applied on.
Usage /NetWarn Rule Player Comment
This action will notify the specified player that they are in violation of the specified rule. The warn action will be logged with the central network database. The user will also receive a BZBB PM with the warning and link to the network rules. Multiple warnings can be issued but must have at least 1 minute duration in between them to allow the user time to discontinue the action. The CANAdmin plug-in will not accept warnings that violate the wait duration.
Usage /NetActivityList Player
This action will list the history of warnings, kicks, bans, silences, and other admin actions stored for the player across all network servers. Each action will list the action, rule violated, the admin, and the comment given at the time of the action. Players have access to a simplified version of this command that will list all the actions for their call sign, but not any others. Server Admins (anyone with an @) also have access to the full version of this command for informational use.
Usage /NetSetIdent SINGLE | CLASSB | CLASS C | HOST | HOSTRANGE Player
This action is only available for unregistered players. It will set the tracking mode for the IP address of the specified player.
SINGLE mode will use the full IP of the user for detection. This is the default mode. CLASSB mode will use the the first 2 sections of an IPV4 address for detection. This is the same as a XXX.YYY.*.* range. CLASSC mode will use the the first 3 sections of an IPV4 address for detection. This is the same as a XXX.YYY.ZZZ.* range. HOST mode will use the reverse DNS host name for detection. HOSTRANGE mode will use the last 3 sections reverse DNS name for detection. This is the same as a *.ISP.DOMAIN.TLD range.
Agents should use the smallest possible range when dealing with unregistered players.
Usage /NetUserInfo Player
This action will return all stored user info for the current player, including there current IP, BZID, Tracking Mode, warn count, ban status/times, and there hostmask. Server Admins (anyone with an @) also have access to the full version of this command for informational use.
Usage /NetSilence Rule Player Comment
This action will block all chat for the specified user on all network services for a period of one hour. The action will also be logged the same way as a warning.
Usage /NetKick Rule Player Reason
This action will force the specified user to disconnect from the server, and disallow any new connections to any network server for a period of no less then 10 minutes. The Kick is network wide, and will prevent immediate rejoins. Users will be given a countdown time each time they attempt to reconnect. This action is logged, and will not be performed by the CANAdmin plug-in unless the user has received 3 or more warnings.
Usage /NetBan Rule Player Reason
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ). This is the harshest action a Field Agent can take, and should only be used as a last resort. Like the kick, the action is logged and can not be applied unless the user has received 3 warnings.
Usage /NetBanCritical Rule Player Reason
This action will force the specified user to disconnect from the server and disallow any new connections to any network server for a period of 336 hours ( 14 days, aka. 2 weeks ), just like a regular NetBan command. In addition this command will flag the ban action for review by the Core Administration team for a possible longer term BAN. This command should not be used lightly or frequently by the Field Agents, and should only be reserved for the worst offenders. Field Agents that abuse this command will face administrative action. Like the NetBan, the action is logged and can not be applied unless the user has received 3 warnings.
All commands that apply limits to users across servers will use ether the BZID of the user, or if unregistered the current tracking mode. If the tracking mode represents a range of IPs, then any user who isn't registered in that IP range will be blocked. Agents need to check and set the tracking mode using /NetSetIdent before applying any actions. The tracking mode will be stored with the user name of the player in the central database.