Principle
Be Clear
Write messages that other members can understand without unnecessary clarification.
Workspace Guidelines
Build Inside a Reliable Workspace.
The Attack On Code workspace is where members communicate, organise missions, manage projects, review work, share knowledge and make decisions.
These guidelines keep the workspace useful, professional, secure and easy to navigate as the community grows.
Core Principles
Every member is expected to follow these standards.
Principle
Be Relevant
Use the correct channel, project space or discussion thread.
Principle
Be Respectful
Disagree with ideas without attacking people.
Principle
Be Accountable
Do not accept tasks and disappear without communication.
Principle
Be Searchable
Write important information in a way that others can find later.
Principle
Be Secure
Do not expose private credentials, internal data or restricted project information.
Principle
Be Constructive
Every discussion should move toward understanding, resolution or action.
Workspace Role
Purpose of the Workspace
The AOC workspace is the operational environment of AOC. It is where members communicate, organise missions, manage projects, review work, share knowledge and make decisions. Casual interaction is welcome, but the workspace must remain functional.
Official announcements
Project coordination
Mission assignment
Technical discussions
Code and design reviews
Documentation
Event planning
Learning resources
Member support
Community collaboration
Profiles
Member Identity
Every member should use a recognisable and consistent identity. Profiles should help members understand who they are working with.
Use your real or commonly recognised name
Recommended format: First Name Last Name
Optional format: First Name | Domain
Add a clear profile picture
Add primary technical domain
Add current role in AOC
Add relevant portfolio or GitHub link where appropriate
Avoid unreadable fonts, excessive emojis, unrelated usernames or intentionally anonymous identities
Messaging
Communication Standards
Workspace communication should preserve context and help other members respond efficiently.
Write complete messages instead of splitting one thought across many messages
Provide context when asking for assistance
Include what you tried, expected outcome, actual outcome and errors or references
Use threads for debugging, mission-specific discussions, feedback and follow-up questions
Tag people responsibly
Avoid unnecessary mass mentions
Keep project discussions in project channels when possible
Organisation
Channel and Space Usage
Each channel or project space should have a defined purpose. Members must read the channel description before posting.
Announcement channels are for official updates by authorised members
General discussion is for community-wide discussion not tied to a specific project or wing
Technical wing channels are for domain-specific conversations
Project channels should include overview, team, milestones, tasks, links, docs, decisions and updates
Mission channels should include title, objective, assigned members, deadline, deliverables, status and blockers
Resource channels should include topic, difficulty, usefulness and review status
Casual channels are for general conversation, introductions, achievements and community interaction
Missions
Mission Workflow Guidelines
Missions are the basic unit of contribution inside AOC. Members should understand the mission before accepting it and communicate progress after accepting it.
Before accepting: review objective, deliverables, required skills, workload, deadline and dependencies
After accepting: confirm acceptance and clarify unclear requirements
Review linked documentation
Communicate your approach
Provide progress updates
Report blockers early
Submit deliverables with work link, summary, limitations, testing, screenshots, document updates and deployment or repository links
Respond to review feedback
Document the final outcome
Status System
Mission Status Labels
Mission status labels keep contributors, reviewers and leads aligned.
Available
Claimed
In Progress
Blocked
Under Review
Changes Requested
Completed
Cancelled
Archived
Projects
Project Workspace Standards
Every official AOC project should maintain a structured workspace with clear ownership, documentation and decision records.
Include project name, problem statement, target users and scope
Include stack, repository links and documentation links
Include team structure, milestones, contribution process and status
Use project channel names like project-aoc-platform or project-examforge
Document technical decisions with problem, options, selected solution, rationale, trade-offs and future changes
Project roles may include Project Lead, Technical Lead, Maintainer, Developer, Designer, Tester, Researcher, Documentation Contributor and DevOps Contributor
Engineering
Code Collaboration Guidelines
Members should follow repository contribution rules and keep pull requests focused, explainable and reviewable.
Understand the mission or issue before coding
Review architecture and contribution guide
Confirm branch and acceptance criteria
Use branch names like feature, fix, docs, refactor or test
Use clear commit messages
Pull requests should include summary, reason, linked issue or mission, screenshots where relevant, testing information, limitations and review notes
Code review should assess correctness, readability, security, performance, maintainability, testing and architectural consistency
Respond to review without defensiveness
Docs
Documentation Guidelines
Documentation is required. Important knowledge should not remain only inside chat messages or individual memory.
Documentation may include README, setup instructions, architecture notes, API references and contribution guides
Documentation may include mission reports, design decisions, troubleshooting guides, user docs and release notes
Docs should be current, clear, structured, concise and stored in an approved location
Avoid ambiguous file names such as final-final.pdf
Important docs should include version number, last updated date, owner and approval status where applicable
Meetings
Meeting Guidelines
Meetings should make decisions, resolve blockers and coordinate work.
Before meetings: define objective, agenda, required attendees, docs, date, time and expected outcome
During meetings: stay on time and relevant to agenda
Avoid interruptions
Record decisions
Identify action items
After meetings: share written summary with decisions, owners, deadlines, unresolved questions and next meeting if required
Availability
Availability and Response Expectations
Members are not expected to remain online continuously, but active contributors must communicate availability.
Urgent blocker: respond when reasonably available
Normal project question: within one to two days
Mission review: per project schedule
General discussion: no mandatory response
Announcements: members must read important updates
If unavailable, post an update in the relevant space
Unexplained inactivity may result in reassignment
Security
Privacy and Security Guidelines
AOC workspace content, credentials and restricted information must be protected.
Do not share private workspace content outside AOC without permission
Never share passwords, API keys, tokens, private keys, database credentials, verification codes or secret environment variables
Use approved secret management
Access should be least-privilege
Report unknown logins, leaks, malicious links, unusual repository changes, compromise or unauthorised access immediately
AI
AI Tool Usage
AI can assist with brainstorming, debugging, docs, tests, code explanation, design exploration, research summaries and productivity. Members remain responsible for final output.
Verify accuracy
Test implementation
Check licences
Remove fabricated information
Ensure no private data exposure
Do not submit code you cannot explain
Disclosure may be required in security, evaluation, licensing or originality-sensitive cases
Conduct
Conduct and Professional Behaviour
Members must follow the AOC Code of Conduct. Criticise work, not people.
No harassment, discrimination, bullying, threats, humiliation or personal attacks
No sexual harassment, hate speech, repeated disruption or targeted exclusion
Conflict resolution should pause, clarify disagreement, provide evidence, involve a lead if needed and document the decision
Avoid retaliation
Do Not
Prohibited Workspace Behaviour
Workspace misuse may lead to restricted access, suspension or removal.
No spam or irrelevant repeated content
No impersonation
No record manipulation
No plagiarism
No leaks
No malware
No illegal promotion
No moderation bypass
No intentional disruption
No access misuse
No harassment
Credit
Promotions, Recognition and Credit
Relevant opportunities may be shared, and meaningful contributions should receive appropriate credit.
Members may share hackathons, internships, OSS programs, events, scholarships, project opportunities and relevant educational resources
Posts should include organiser, deadline, eligibility, official link and verification status
No misleading promotions, referral spam or unrelated advertising
Do not claim others work
Do not remove attribution
Do not exaggerate your role
Project docs should identify major contributors and maintainers
Leadership
Leadership Responsibilities
Leadership is a service role. Leaders, maintainers and coordinators must model workspace standards.
Communicate expectations
Avoid favouritism
Review fairly
Protect contributors from humiliation
Document decisions
Assign realistic workloads
Respond to blockers
Manage access responsibly
Reporting
Moderation and Reporting
Reports should be handled confidentially by authorised members. No retaliation for genuine reports.
Possible actions include informal warning, formal warning, message removal, temporary communication restriction, project removal, suspension, access revocation or permanent removal
Action depends on severity, repetition, impact, intent and previous behaviour
Report harassment, misconduct, security concerns, plagiarism, privacy violations, abusive leadership or workspace misuse
Reports should include what happened, when, where, screenshots or links, involved members and immediate risk
Structure
Recommended Workspace Organisation
AOC workspace organisation should make important information easy to find and project work easier to coordinate.
Start Here: welcome, rules, announcements, onboarding, introductions, FAQ
Community: general, achievements, opportunities, resources, casual
Technical Wings: web development, artificial intelligence, competitive programming, game development, design, research, open source, DevOps
Projects: project-specific spaces, announcements, documentation and reviews
Missions: available, active, reviews and completed
Operations: events, partnerships, content, marketing and member support
Leadership: restricted areas for Core Council, maintainers, wing coordinators and moderation
Checklist
Before Posting Checklist
Correct channel?
Clear message?
Enough context?
Should this be a thread?
Already exists?
Sharing anything private?
Need to tag someone?
Respectful?
Useful outcome?
Checklist
Before Accepting Work Checklist
Understand objective
Understand deliverables
Know deadline
Have required access
Have enough time
Know reviewer
Know where to report progress
Will communicate if blocked
Final Workspace Standard
Clear communication creates reliable teams.
The quality of the AOC workspace reflects the quality of the community. Use the workspace to build. Use it to learn. Use it to support other contributors. Do not use it merely to appear active.
Reliable teams create meaningful work. Meaningful work creates Attack On Code.