DWIRC:Staff Training/Code of Conduct

DarkWorld IRC Network
Staff Code of Conduct

Applies to	IRC staff candidates, trainees, probationary staff, permanent staff, operators, Services staff, and administrators
Scope	DarkWorld IRC Network
Acceptance	Mandatory before final assessment and probation
Enforcement	DarkWorld IRC management and authorized reviewers
Related program	DarkWorld IRC Staff Training Program

1. Purpose

The DarkWorld IRC Staff Code of Conduct establishes the standards of behavior, integrity, security, and accountability required from everyone serving or training to serve within the DarkWorld IRC Network.

DarkWorld IRC staff may receive trusted access to:

• IRC users and channels.
• Restricted staff channels.
• IRC operator commands.
• IRC Services.
• Account and channel information.
• Abuse reports.
• Policy and approval systems.
• Logs and operational information.
• Network servers and infrastructure, where separately authorized.

This access must be used only to support, protect, and operate the DarkWorld IRC Network.

2. Scope

This Code applies to:

• Staff applicants where relevant.
• IRC students and trainees.
• Probationary IRC staff.
• Support staff.
• Channel-support staff.
• IRC operators.
• Global IRC operators.
• Services staff.
• Services administrators.
• Policy and compliance staff.
• Abuse and security staff.
• IRCd and network administrators.
• Root administrators.
• Management personnel exercising DWIRC authority.
• Temporary or emergency staff appointments.

The Code applies whenever a person:

• Uses DarkWorld IRC staff access.
• Represents DarkWorld IRC officially.
• Handles DarkWorld IRC information.
• Participates in a DWIRC investigation.
• Uses a staff bot, website, API, or administrative system.
• Performs a task on behalf of the IRC network.

3. Relationship to DarkWorld Network

DarkWorld Network is the wider umbrella under which DarkWorld IRC and other projects operate.

DWIRC staff authority does not automatically grant authority over:

• DWShells.
• DWBouncers.
• DWBots.
• DWGames.
• DWVPN.
• Websites.
• Hosting systems.
• Other DarkWorld projects.
• Registered external projects.

Any role in another project requires separate authorization, training, and access.

4. Commitment to Service

Staff members shall:

• Act in the interests of the IRC network and its community.
• Help users patiently and professionally.
• Protect users from abuse.
• Maintain network stability.
• Apply policies fairly.
• Cooperate with other authorized staff.
• Respect legitimate channel autonomy.
• Escalate matters outside their authority.
• Place operational responsibility above personal status.

Staff access is a responsibility, not a personal entitlement.

5. Respectful Conduct

Staff members shall:

• Treat users and staff respectfully.
• Communicate clearly and professionally.
• Avoid insults, ridicule, humiliation, and intimidation.
• Avoid discriminatory treatment.
• Remain calm during disagreements.
• Recognize language and accessibility barriers.
• Avoid unnecessary public confrontation.
• Correct misinformation without attacking the person.
• Set appropriate boundaries when users become abusive.

Staff members remain entitled to protection from harassment and are not required to tolerate threats or sustained abuse.

6. Neutrality and Fairness

Staff members shall:

• Apply rules consistently.
• Base decisions on policy and evidence.
• Judge conduct rather than personal popularity.
• Avoid favoritism.
• Avoid harsher treatment of personal rivals.
• Avoid special treatment for friends.
• Respect the right to appeal.
• Correct inconsistent enforcement.
• Avoid prejudging cases publicly.

Nationality, race, religion, gender, disability, language, age, political view, technical ability, or social status must not be used as a basis for unfair treatment.

7. Proportionate Use of Authority

Staff shall use the least severe effective action.

Before significant enforcement, staff should consider:

• What happened.
• Which policy applies.
• Whether the incident is ongoing.
• The severity and impact.
• The reliability of the evidence.
• Previous relevant conduct, where authorized.
• Whether a warning is appropriate.
• Whether innocent users may be affected.
• Whether escalation is required.
• Whether the action can be safely reversed.

Emergency protective action may be taken when delay would cause further harm, but it must be reviewed and documented afterward.

8. Prohibited Abuse of Authority

Staff members must not:

• Use access to win a personal dispute.
• Threaten users with staff powers.
• Ban users for respectful criticism.
• Remove access as retaliation.
• Investigate users out of curiosity.
• Enter restricted channels without an operational reason.
• Use OperOverride for personal purposes.
• Use forced mode commands for convenience.
• Disconnect users as a joke.
• Grant unauthorized access to friends.
• Take over channels.
• Manipulate project approvals.
• Override another team without authority.
• Conceal or falsify staff actions.
• Use private information for personal advantage.

9. Conflicts of Interest

Staff must disclose a meaningful conflict when:

• A friend or family member is involved.
• A personal rival is involved.
• The staff member’s own project is involved.
• A competing project is involved.
• The staff member may receive a benefit.
• The staff member previously participated in the dispute.
• Their own action is being appealed.
• Their neutrality may reasonably be questioned.

When a conflict exists, the staff member shall:

1. Protect users from immediate harm if required.
2. Preserve relevant evidence.
3. Disclose the conflict internally.
4. Transfer the final decision to a neutral reviewer.
5. Avoid improperly influencing the review.
6. Record the reassignment.

10. No Retaliation

Staff must not retaliate against anyone for:

• Submitting a complaint.
• Appealing an action.
• Reporting a security concern.
• Providing evidence.
• Reporting staff misconduct.
• Refusing an unauthorized request.
• Respectfully criticizing a decision.
• Participating in an investigation.

Retaliation is considered a serious breach of staff trust.

11. Privacy and Confidentiality

Staff shall protect:

• IP addresses.
• Hidden host information.
• Email addresses.
• Account information.
• Private logs.
• Abuse reports.
• Staff discussions.
• Server notices.
• Security details.
• Application records.
• Bot and API information.
• Credentials.
• Other restricted data.

Confidential information may be accessed only when required for an authorized duty.

Staff must not:

• Post private evidence publicly.
• Share restricted information with friends.
• Relay staff-channel content externally.
• Publish private information on social media.
• Keep unnecessary personal copies.
• Access private information from curiosity.
• Use confidential information after leaving staff.
• Reveal security controls without authorization.

Confidentiality obligations continue after resignation, inactivity, suspension, or removal.

12. Credential Security

Staff shall:

• Use strong and unique passwords.
• Keep NickServ and operator passwords separate.
• Use verified TLS.
• Use SASL where appropriate.
• Enable additional authentication where supported.
• Protect recovery codes.
• Secure IRC clients and devices.
• Protect SSH keys, API tokens, and certificates.
• Remove credentials from retired devices.
• Report exposure immediately.
• Follow credential-rotation instructions.

Staff must never:

• Share passwords.
• Send credentials through IRC.
• Store secrets in public paste services.
• Commit secrets to public repositories.
• Post screenshots containing credentials.
• Ask another staff member to share their access.
• Permit another person to use their staff identity.

Every action performed through a staff account is presumed to be the responsibility of its assigned holder unless a compromise is properly reported and investigated.

13. Device and Client Security

Devices used for staff duties should:

• Receive security updates.
• Use screen locking.
• Use secure user accounts.
• Use device encryption where practical.
• Avoid untrusted software.
• Protect log files.
• Restrict remote access.
• Be reported if lost or stolen.

Privileged sessions must not be left open on public or shared computers.

Unreviewed IRC scripts, plugins, bots, or automation must not be used with privileged access when they could expose credentials or send administrative commands.

14. Evidence Integrity

Staff shall:

• Preserve relevant evidence accurately.
• Keep original evidence where possible.
• Use clear timestamps.
• Distinguish facts from reports and inferences.
• Identify evidence sources.
• Protect restricted evidence.
• Record corrections.
• Preserve records of staff actions.

Staff must not:

• Fabricate messages.
• Alter logs dishonestly.
• Delete records to hide mistakes.
• Present partial evidence as complete.
• Add false timestamps.
• Misrepresent allegations as confirmed facts.
• Collect unrelated personal information.
• Obstruct an authorized investigation.

Intentional evidence falsification may result in immediate access suspension or removal.

15. Staff Action Records

Significant actions should record:

• Date and time.
• Staff member.
• Target.
• Relevant account or channel.
• Action performed.
• Reason.
• Policy.
• Scope.
• Duration.
• Evidence reference.
• Authorization where required.
• Impact on other users.
• Review date.
• Final outcome.

Staff must not falsely claim that:

• A warning was delivered.
• Management approved an action.
• Evidence was reviewed.
• A user admitted an allegation.
• An action was technically required.

16. User and Channel Information

Staff must recognize that:

• A nickname is not proof of legal identity.
• A displayed real name may be false.
• A shared host does not prove users are the same person.
• VPNs, bouncers, shells, gateways, and relays may serve many users.
• Similar behavior is not conclusive identity evidence.
• Registered-account data must be handled appropriately.
• Channel ownership disputes require authorized review.

Staff must avoid applying broad restrictions without considering innocent users.

17. Channel Autonomy

Registered channel founders and authorized channel staff generally manage their channels.

IRC network staff shall not override channel management merely because:

• They dislike a channel rule.
• A friend was removed.
• They want channel access.
• They disagree personally with the founder.
• They hold IRC operator status.

Network intervention may occur when:

• A network policy is violated.
• Serious abuse is occurring.
• Network infrastructure is threatened.
• An authorized appeal requires review.
• Management directs intervention.

18. Services Administration

Account and channel administration must follow authorized Services procedures.

Staff must not:

• Ask for NickServ passwords.
• Identify to a user’s account.
• Change a founder based on friendship.
• Drop a channel casually.
• Transfer account ownership without verification.
• Use OperServ to avoid normal procedures.
• Reveal restricted Services information.
• Suspend accounts for personal reasons.
• Change vhosts to impersonate staff or projects.

High-risk Services actions require the appropriate role, evidence, authorization, and documentation.

19. Operator Conduct

IRC operators shall:

• Use operator access only for network duties.
• Confirm command targets.
• Check restriction scope and duration.
• Consider shared-host effects.
• Use professional reasons.
• Coordinate during incidents.
• Protect server notices.
• Record significant actions.
• Correct mistakes promptly.
• Avoid dangerous server commands without authorization.

Operator access does not place a staff member above the rules.

20. Staff Communication

Staff shall:

• Keep operational communication factual.
• Avoid public arguments with other staff.
• Move internal disagreements to approved staff channels.
• Follow the incident lead during active emergencies.
• Avoid unsupported public claims.
• Distinguish personal views from official statements.
• Protect private evidence.
• Correct inaccurate information.

Restricted staff channels must not be treated as spaces where harassment, discrimination, or dishonest conduct is acceptable.

21. Public Representation

When representing DarkWorld IRC, staff must:

• Use approved information.
• Avoid making unauthorized promises.
• Avoid speaking for unrelated DarkWorld projects.
• Avoid disclosing confidential investigations.
• Avoid announcing unconfirmed incidents.
• Direct users to official documentation.
• Follow authorized announcement procedures.
• Correct errors transparently.

Staff should not create unofficial “staff notices” that may be confused with formal network policy.

22. External Roles and Communities

Relevant positions on other IRC networks or projects should be disclosed when they may create a conflict.

Staff must not:

• Share DarkWorld operational information externally.
• Recruit DarkWorld users for another network.
• Transfer private reports between networks without authority.
• Use DarkWorld information to benefit a competing project.
• Give external administrators access to DarkWorld systems.
• Coordinate external retaliation against a user.

An external role is not automatically prohibited, but strict separation is required.

23. Gifts and Personal Benefits

Staff shall not accept money, services, access, hosting, accounts, subscriptions, favors, or other benefits in exchange for:

• Approving an application.
• Removing a restriction.
• Changing channel ownership.
• Granting staff access.
• Ignoring a violation.
• Sharing private information.
• Granting verified presence.
• Influencing an investigation.

Any attempt to improperly influence a decision should be disclosed.

24. Bots, APIs, and Automation

Staff using PolicyServ, RelayServ, Services, bots, APIs, or administrative websites shall:

• Protect authentication tokens.
• Use only assigned permissions.
• Verify targets and statuses.
• Record administrative actions.
• Investigate unexpected responses.
• Avoid using bots outside approved channels.
• Verify high-impact results.
• Report failed or unauthorized operations.
• Revoke access when no longer required.

Automation assists staff; it does not remove human responsibility.

25. Staff Mistakes

When a staff member makes a mistake, they shall:

1. Stop continuing harm.
2. Correct the action where authorized.
3. Report the mistake.
4. Preserve the original record.
5. Document the correction.
6. Inform affected users appropriately.
7. Cooperate with review.
8. Complete additional training where required.

Honest reporting and correction will be considered during review.

Concealment, evidence deletion, dishonesty, or retaliation will be treated as separate violations.

26. Security and Privacy Incidents

Staff must immediately report:

• Compromised credentials.
• Lost or stolen devices.
• Unauthorized staff access.
• Exposure of private user information.
• Suspicious operator actions.
• Leaked tokens or keys.
• Malware on a privileged device.
• Serious vulnerabilities.
• Services impersonation.
• Staff-account takeover.

Staff must not continue using credentials believed to be compromised.

27. Vulnerability Handling

Staff discovering a possible vulnerability shall:

• Avoid unnecessary exploitation.
• Avoid accessing unrelated data.
• Preserve minimal evidence.
• Report privately to authorized technical staff.
• Avoid premature public disclosure.
• Follow the responsible investigation process.
• Assist with testing only when authorized.

No staff role automatically authorizes penetration testing against production systems.

28. Staff Cooperation

Staff shall:

• Respect defined responsibilities.
• Share necessary operational information.
• Support incident leadership.
• Avoid duplicate or conflicting commands.
• Hand over active cases properly.
• Respond to authorized reviews.
• Assist with documentation.
• Accept corrections professionally.
• Report unresolved procedural problems.

Staff must not obstruct another authorized team’s investigation or deliberately interfere with network recovery.

29. Activity and Reliability

Staff should:

• Meet reasonable activity expectations.
• Inform the team about extended absence.
• Hand over active cases.
• Review temporary restrictions before leaving.
• Secure privileged sessions.
• Respond to important access reviews.
• Keep contact information current through approved systems.

Inactivity may result in access reduction or removal for security purposes.

30. Staff Access Review

Staff access may be reviewed when:

• A role changes.
• A staff member becomes inactive.
• A credential is exposed.
• An incident occurs.
• A complaint is received.
• New permissions are requested.
• A project relationship changes.
• A staff member resigns.
• Management performs a periodic security review.

Staff shall cooperate with access reviews.

31. Suspension of Access

Access may be temporarily suspended to protect the network when:

• An account may be compromised.
• A device is lost.
• Serious misuse is alleged.
• A staff member repeatedly acts unsafely.
• An independent investigation is required.
• Continued access creates operational risk.
• A role no longer requires the access.

Temporary suspension does not by itself prove misconduct.

Staff must not evade a suspension by using another account.

32. Resignation and Removal

When staff service ends:

• Operator access must be removed.
• Services permissions must be reviewed.
• Staff-channel access must be removed.
• Tokens and keys must be revoked or rotated.
• Active cases must be transferred.
• Restricted documents must remain protected.
• Project-specific roles must be reviewed separately.
• The offboarding process must be documented.

Former staff must not retain, publish, or misuse confidential information.

33. Reporting Violations

Suspected violations of this Code should be reported through an approved confidential process.

A report should include:

Date and time:
Reporting person:
Staff member involved:
Location:
Conduct reported:
Evidence available:
Immediate risk:
Actions already taken:
Potential conflict of interest:
Requested review:

Reports should be handled by an appropriate and, where necessary, independent reviewer.

Knowingly false reports may themselves violate policy, but an unproven good-faith report is not automatically a false report.

34. Protection of Reporters

Anyone submitting a good-faith report should be protected from retaliation.

Staff must not:

• Reveal a reporter unnecessarily.
• Threaten the reporter.
• Deny support in retaliation.
• Manufacture a sanction.
• Pressure the reporter to withdraw.
• Destroy the report.
• Send the complaint only to the accused person where independent review is required.

35. Investigation Principles

A staff-conduct investigation should be:

• Authorized.
• Confidential.
• Evidence-based.
• Proportionate.
• Independent where required.
• Documented.
• Free from retaliation.
• Completed within a reasonable operational period.
• Open to correction if new evidence appears.

The investigator should distinguish:

• Confirmed facts.
• Reports.
• Inferences.
• Disputed claims.
• Missing evidence.

36. Possible Outcomes

Depending on severity and evidence, outcomes may include:

• No violation found.
• Guidance.
• Informal correction.
• Formal warning.
• Additional training.
• Increased supervision.
• Reduced permissions.
• Temporary suspension.
• Role reassignment.
• Removal from a specific team.
• Removal from DWIRC staff.
• Permanent revocation of privileged access.
• Network action for separate user-policy violations.

Serious intentional misconduct may justify immediate removal.

37. Factors in Staff Discipline

Reviewers may consider:

• Severity.
• Intent.
• Harm caused.
• Number of users affected.
• Whether private information was exposed.
• Whether credentials were compromised.
• Previous relevant conduct.
• Cooperation with the investigation.
• Honesty.
• Corrective action.
• Retaliation.
• Evidence concealment.
• Risk of recurrence.
• Position and level of trust.

Senior access creates greater responsibility, not greater immunity.

38. Appeals

Where an appeal process is available, the affected staff member may request review.

An appeal should:

• Identify the decision.
• State the reason for disagreement.
• Provide relevant evidence.
• Avoid retaliation or disruption.
• Follow the approved process.

An appeal does not automatically restore suspended access.

39. Code Acceptance

Before final assessment or probation, each candidate must affirm:

I have read and understood the DarkWorld IRC Staff Code of Conduct.

I understand that staff access exists only for authorized DarkWorld IRC
responsibilities and does not automatically extend to other DarkWorld projects.

I agree to protect credentials, user information, incident evidence, staff
communications, and all other confidential information.

I will not use staff authority for personal disputes, favoritism, retaliation,
financial benefit, curiosity, or unauthorized access.

I will disclose relevant conflicts of interest and will request independent
review when my neutrality may reasonably be questioned.

I will use the least severe effective action, document significant actions,
report mistakes honestly, and cooperate with authorized investigations.

I understand that training completion does not guarantee appointment and that
staff access may be limited, reviewed, suspended, or removed to protect the
DarkWorld IRC Network.

I understand that my confidentiality obligations continue after I leave the
staff team.

Registered account:
Current nickname:
Candidate status:
Date accepted:
Method of acceptance:
Witness or trainer:

40. Acceptance Methods

Management may accept the Code through:

• A staff-training website.
• A wiki-linked application system.
• An authenticated IRC bot command.
• A signed digital form.
• A recorded staff-channel procedure.
• Another approved method.

Acceptance should record:

• Registered account.
• Current version of the Code.
• Date and time.
• Acceptance method.
• Candidate status.
• Reviewing staff member.
• Any declared conflicts or external roles.

41. Code Versioning

This Code should include a version and revision date when formally adopted.

Example:

Code version	1.0
Effective date	To be approved
Last reviewed	To be recorded
Approved by	DarkWorld IRC Management

When material changes are made:

• Staff should be notified.
• The revision should be recorded.
• Significant changes should be explained.
• Re-acceptance may be required.
• Previous versions should be preserved for audit purposes.

42. Candidate Review Questions

Before accepting this Code, answer:

1. What is the purpose of staff authority?
2. Does DWIRC staff access extend automatically to DWShells or DWBouncers?
3. When must a conflict of interest be disclosed?
4. What is retaliation?
5. May staff reveal a hidden IP address to prove a point?
6. What should happen after a credential leak?
7. May OperOverride be used to enter a private channel out of curiosity?
8. How should a staff mistake be handled?
9. What is the difference between suspension and a finding of misconduct?
10. Why must significant actions be recorded?
11. How should a complaint against a staff member be reviewed?
12. Do confidentiality obligations continue after resignation?
13. Can a staff member accept free hosting in exchange for an approval?
14. What should happen when a user is affected by an incorrect ban?
15. Does completing training guarantee a staff appointment?

43. Completion Requirement

To complete this page, the candidate must:

• Read the entire Code.
• Correctly answer at least 13 of the 15 review questions.
• Disclose relevant external roles and conflicts.
• Accept the Code through an approved method.
• Receive trainer confirmation.
• Agree to comply throughout training, probation, and staff service.

Refusal to accept the Code makes the candidate ineligible for staff access.

44. Next Step

After accepting the Code, continue to:

DarkWorld IRC Staff Final Written Examination

---

Previous: Module 10 — Staff Ethics and Security Program: DarkWorld IRC Staff Training Program Next: Final Written Examination