How we use Linear

We follow the Linear Method as closely as practical and keep issues lightweight, actionable, and owned.

Teams

• Engineering is the primary team for Bubble Engineering work.
• Sub-teams: Backend, Raven, Platform (used for repository work outside Bubble Engineering).

Issue standards

• One issue per atomic task; avoid user stories in favor of clear tasks.
• Engineers should create their own issues when possible to plan work.
• Every issue must include scope, priority, and a Type label.
• Issues should be complete enough to be actionable without extra back-and-forth.
• Keep the product context in the project; keep issues short with just enough detail.
• Keep the issue status current; Linear workflows are status-driven.

Projects

• Product requirements and project context live at the Project level.
• Engineers should reference the project in issues instead of duplicating specs.

Type labels

Each issue must have one label from the Type group:

• Feature
• Tech Debg
• Bug:Production
• Bug:QA
• Service Request
• Wontfix
• Vulnerability

Triage

• Bugs and service requests may enter through triage and be assigned afterward.

Status automation (GitHub)

• Draft PR opened: move to In Progress if not already.
• PR opened: move to In Review.
• PR merged: move to Completed.
• Link PRs to issues to keep status updates and auto-completion working.

Cycles and estimates

• Cycles are 2 weeks with no cooldown.
• We use Fibonacci estimates (1–8).

Branches and PRs

• One Linear issue maps to one branch and one PR.
• Use the suggested branch name from Linear when possible.