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

Was this helpful?

  1. Engineering

How to report issues

Always create a Linear ticket first unless it’s

  • a severe security concern or

  • a bug that is user-specific / includes user information / doesn’t require code changes

  1. Create the issue in Linear

    • At this point, it should go into Triage. From there, the Product team will triage the issue, decide its priority and will plan it to be worked.

    • If the issue is a urgent bug that we need to fix now, it can be Accepted and put directly into In Progress

      • Ensure you've correctly set the Project on the Linear issue to correspond with the current release we are working on (e.g. v3.6, v3.7, etc.)

    • If it's more an internal task we don't want the GitHub community to see, put the private label on the issue so it's not synced.

    • There have been many Linear/GitHub issues created with just a link to Threads. We need to stop doing this since community members do not have access to Threads.

  2. Add all the labels (bug, etc.)

  3. Only open a thread if the issue is Urgent and we need to coordinate the work immediately.

    • Otherwise, new threads should not be created in the normal course of working issues.

    • Let's try to keep discussions about how to implement a feature or bug in Linear/GitHub. This will provide more content on the project itself instead of hidden in Threads.

PreviousValuable BookmarksNextHow we work on Tickets

Last updated 1 year ago

Was this helpful?

πŸ›