2 Communication Guidelines

Overall we try to keep in touch via Slack, Github, and Google docs. Each has their strengths and weaknesses for communication and the right tool should be used in accordance with the needs of the communication.

2.0.1 Preferred Channels & In‑Channel Norms

Slack (primary, in‑channel by default): Day‑to‑day collaboration, quick questions, updates. Use team channels for team matters; keep DMs for sensitive or 1:1 topics. This is not a long term record. So for valuable information keep it in a doc. For technical information keep it on github.
1. Meeting invites/links, resources, files, status updates, questions, blockers, insights and learnings in‑channel.
2. Respect people’s attention. A single carefully thought through message to distract once instead of multiple short ones can avoid unnecessary distraction and improve single-to-noise ratio of the medium.
3. Use threads to keep things tidy, @mention owners, and keep the general noise low on a channel. Others can review if they want but otherwise only the thread members are notified.
4. If someone DMs you about work, reply: “Let’s move this to #concerned-channel so everyone has context.”
5. Post quick summaries/decisions after calls. Record meetings and share the transcript/summary link in the channel.
6. Update the channel with any decision/conclusion made after the meet.
7. All work‑related communication happens in team/project channels. If it’s work, it lives in a channel.
8. Use channel topics to state purpose/scope; keep them current.
9. Pin/Bookmark the index, roadmap, runbooks, and latest demo.
10. Prefer posts (long‑form messages) for announcements or complex updates.
Email: Formal communication, external/client correspondence, or when discoverability/audit trail is required. Use concise subjects (e.g., [ACTION], [DECISION], [INFO]), put the task in the first line, and link to the source task/doc. CC only those needed; move long threads into a doc/task and post the link.
Project Management tools: (e.g., Github issues): Tasks, scope, deadlines, acceptance criteria. : Future scope
Convert requests into tasks with owner, due date, acceptance criteria, and links. Keep status current; comment in the task instead of side DMs.
Video (e.g., Google Meet): Scheduled meetings, workshops, 1:1s, client calls. Join on time, test mic/cam, cameras on when feasible. Record and save per Meetings & Project Management section Meeting Etiquette. Share the notes/summary link in‑channel post‑call.
Phone/WhatsApp: Urgent only or when internet fails; summarize outcomes back in Slack or the PM tool. There will be no Project discussion on Phone/Whatsapp, only use it to inform if there is a power outage, or if Slack is down. First try to reach out with mail, if it fails then only opt for these.

2.0.2 Response‑Time SLAs (Business Days)

Slack: Acknowledge within 15-30 minute during your stated work window. Use emoji/short ack if busy; follow with substance when free.
Email: Acknowledge within 1-2 working hours; urgent emails: respond same day where feasible.
PM Tool Mentions (@): Acknowledge within 2-3 working hours; update task by the due date.
Escalation: If blocked > 1 working hours, escalate in the task and tag the manager/owner; Post in #i-am-blocked while you keep working on it.

2.0.2.1 Additional Pointers:

SLA(Service Level Agreement) clock runs only during stated work windows; outside those hours, assume next‑day.
Use [URGENT] in the first 3 words for truly time‑critical items; otherwise avoid urgency labels.
Always leave a breadcrumb: react with 👀 for “seen” and ✅ when resolved.
If you’ll need >1h for a thoughtful reply, acknowledge with an ETA.
When you hand off across time zones, summarize the current state + exact ask.
If a message is idle for > 1h, the sender should bump once with an @mention.

2.0.3 Etiquette & Inclusivity

Default to clear, concise, and kind. Assume positive intent.
Use status (Available/Focus/OOO) and scheduled send outside colleagues’ work windows.
Prefer public channels over DMs for transparency and shared learning.
Record decisions as a one‑liner in the relevant task/doc (Decision: …, Owner: …, Date: …).
Keep notifications sane: threads for sub‑topics; avoid @channel/@here unless necessary.

2.0.3.1 2.0.3.2 Additional Pointers:

Prefer threads for follow‑ups; keep channels scannable with short subject lines in the first sentence.
Use people’s names when assigning work; avoid vague “someone” asks.
Assume async: include context, links, and what “good” looks like.
Accessibility: enable captions, avoid tiny fonts in screenshots, and briefly describe visuals when useful.
Avoid sarcasm/inside jokes in decision threads; keep signals high.

2.0.4 Official Slack Channels (Company‑Wide)

#all-pihexlabs: Announcements only; ask questions in a thread. Use reactions (✅/❓) to acknowledge.
#team-announcements: Managers/leads post; teammates reply in thread if action is required.
#help-desk: Include system, link, screenshots, and urgency. One issue per thread; update when resolved.
#i-am-blocked: Follow Meetings & Project Management section format; add what you tried and the specific ask. Keep the thread updated until unblocked.
#check-in-check-out: Post within your first/last hour. If you split your day, do a brief mid‑day update.
#away-notes: Include start/end time, reason, and coverage plan if relevant.
#resources_documents_links: Prefix with tags like [SOP], [RFC], [Template]; keep links current.

2.0.5 Slack Project Channels (Dynamic)

Project channels are created per engagement and may be archived as work completes. Examples include:
#agentic-data-conversion, #deployment-security-infrastructure, #rockfield-website, #pythonaisolutions-website, #niivue, #nihfmrif-scheduler.

Rule of thumb: keep project‑specific discussions inside the relevant channel; cross‑post summaries to #all‑pihexlabs only when broadly relevant.

2.0.5.1 Additional Pointers:

Channel topic should state scope, owner, and start date; keep it current.
Name projects consistently: #project-name where possible.
Pin: index post, roadmap/board, runbooks, contacts, latest demo.
Archive channels within 14 days of project close after posting a final summary + handoffs.

2.0.6 OOO & Leave Notices

Short absence (≥1 hour): post in #away-notes with a time window.
Planned leave/holidays: Add to shared calendar as soon as you know. For planning purposes the earlier you enter this the better. Removing entries when you change your mind is fine.
Emergency leave: notify manager via Slack/phone; HR will record and advise next steps if necessary.

2.0.6.1 Additional Pointers:

Planned leave: give ≥10 business days’ notice where possible; client‑facing roles aim for ≥20.
Include coverage plan or backup contact when relevant.
For the same‑day sickness, send a brief note before your usual start time.