Slack Conventions
Slack is EGI's primary internal communication tool. These conventions ensure channels stay organized, searchable, and useful as the team and project count grows.
Channel Naming Conventions
All channel names use lowercase with hyphens. Prefixes indicate the channel's purpose.
| Prefix | Format | Purpose | Example |
|---|---|---|---|
#project- | #project-[name] | Internal work for a specific project | #project-life-central |
#client- | #client-[name] | Slack Connect channel shared with a client | #client-acme-corp |
#team- | #team-[function] | Functional team discussions | #team-engineering, #team-design |
#cross- | #cross-[company]-[company] | Cross-company coordination | #cross-egi-anchor |
#ops- | #ops-[system] | Automated alerts and operational feeds | #ops-deployments, #ops-alerts |
#general | -- | Company-wide announcements and general discussion | -- |
#random | -- | Non-work conversation | -- |
Naming Rules
- Use the shortest unambiguous project or client name (e.g.,
#project-plcnot#project-project-life-central) - Never include dates or version numbers in channel names
- Archive channels when a project is complete or a client engagement ends; do not delete them
Required Channels Per Project
Every active project must have the following channels created at kickoff:
#project-[name]-- Internal engineering and design discussion#client-[name]-- Shared channel with the client (Slack Connect)#ops-[name]-deploys-- Automated deployment notifications for the project (optional for internal-only projects)
If the project involves a handoff to Anchor MSP, create #cross-[name]-handoff at the start of the handoff phase.
Mentions and Notifications
@here vs @channel
| Mention | Use When | Effect |
|---|---|---|
@here | You need attention from people currently online in the channel | Notifies only active members |
@channel | The message is critical and everyone in the channel must see it, regardless of online status | Notifies all members, including those with notifications paused |
Rules:
- Default to
@herefor most situations @channelis reserved for production incidents, urgent blockers, and time-sensitive announcements- Never use
@channelin#generalor#randomwithout leadership approval - For individual attention, tag the person directly (e.g.,
@elliott)
@team Mentions
Use Slack user groups for team-level pings:
@egi-engineering-- All EGI engineers@egi-leads-- Project and team leads@anchor-ops-- Anchor MSP operations team
Thread Etiquette
- Always reply in threads. Top-level messages in a channel should be new topics only. All follow-up discussion belongs in the thread.
- Use "Also send to channel" sparingly -- only when the reply contains a resolution or decision that everyone in the channel needs to see.
- Summarize long threads. If a thread exceeds 15 messages, post a top-level summary with the key decision or outcome and link back to the thread.
- Do not start new threads to continue an existing conversation. Find the original thread and continue there.
Bot Integrations
The following bots post automated updates to designated channels. Do not mute these channels if you are on the relevant project.
| Bot | Channel(s) | What It Posts |
|---|---|---|
| GitHub | #ops-[name]-deploys, #project-[name] | PR opened, merged, CI status, review requests |
| Vercel | #ops-[name]-deploys | Deployment started, succeeded, failed, preview URLs |
| PostHog | #ops-alerts | Threshold alerts, anomaly detection, funnel breakdowns |
| Uptime / Monitoring | #ops-alerts | Downtime alerts, SSL expiry warnings, health check failures |
| SuiteDash | #client-[name] (optional) | New client messages or file uploads |
Managing Bot Noise
- Configure bots to post only actionable events (e.g., filter out draft PR updates)
- Use Slack channel-level notification overrides if a bot channel is too noisy for your workflow
- Review bot configurations quarterly and remove integrations that are no longer relevant
Status Conventions
Set your Slack status to communicate availability clearly.
| Status Emoji | Meaning | Expected Response Time |
|---|---|---|
| No status set | Available, working normally | Standard (within 2 hours) |
| 📆 (Calendar) | In a meeting | After the meeting ends |
| 🎧 (Headphones) | Deep focus / heads-down work | Within 4 hours or after focus block ends |
| 🌴 (Palm tree) | Out of office / PTO | Not expected to respond; check back on return date |
| 🏠 (House) | Working remotely (if relevant) | Standard (within 2 hours) |
| 🤒 (Sick) | Out sick | Not expected to respond |
Status Rules
- Update your status before you become unavailable, not after
- Include a return time or date when possible (e.g., "In meetings until 2 PM")
- Clear your status when you are available again
Channel Lifecycle
- Creation: Project lead creates required channels at project kickoff and sets the channel topic and description
- Active use: Follow all conventions above during the project
- Archival: Within 2 weeks of project completion or client disengagement, archive the channel. Post a final message linking to the project retrospective or handoff documentation before archiving
- Retrieval: Archived channels are searchable. If a project is reactivated, unarchive the original channel rather than creating a new one
Do's and Don'ts
Do:
- Pin important messages (project briefs, key decisions, environment URLs)
- Use emoji reactions to acknowledge messages without cluttering the thread (e.g., ✅ for "done", 👀 for "looking into it")
- Keep file sharing in Slack to quick references only; permanent files belong in SuiteDash or the project repository
Don't:
- Send messages that say only "Hi" or "Hey" and wait for a response; include your question or context in the first message
- Use Slack for formal approvals or contractual communication
- Create private channels for project work unless there is a specific confidentiality requirement approved by a lead