LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page
  • Here's how to know what to use:
  • The "Thread Police"
  • Threads Best Practices

Was this helpful?

  1. Policies

Communications

We use threads.com and gitbook.com for communications.

Threads.com has:

  • threads and

  • group messages (#General and #Engineering, potentially #Operations and #Marketing later)

  • direct messages

GitBook has:

  • long-form entries and playbooks

Here's how to know what to use:

  • things that are only relevant for today => group message in #General / #Engineering

    • Example: "hey ESLint is breaking for me, can someone help?"

  • things that are for a week up to a month => thread (see below for etiquette)

    • Example: RFCs, Bug Reports, Sales Notes, ...

  • things that are only relevant for one person => direct messages

    • Example: "Hey can you book my link for peer programming?"

  • things that are relevant forever and future hires => GitBook

    • Example: This entry

The "Thread Police"

One thing we've adopted company-wide is the "Thread Police" 🚓🚓🚓🚓 essentially when a conversation either goes out-of-topic or is too sync-heavy (i.e. too many people chiming in, too many different opinions etc.) we move things into an async thread.

Threads are more structured and less noisy, async friendly and easier to follow up at a later time.

Anyone who keeps talking about this topic in the sync chat afterwards goes to async-jail immediately, you do not pass Go and do not collect $200.

Threads Best Practices

Using Blocks

Using blocks allows others to reply to specific ideas and/or sections of a thread instead of a large piece of text. Simply hit "enter" to add more blocks. See the example below:

PreviousExpensesNextManaging Notifications

Last updated 1 year ago

Was this helpful?

Every employee in the team is empowered to share the "Thread Police" emojis when they feel like something gets out of hand in a group chat.

🗣️
🚓
🚓
🚓