Skip to main content

Draft Pull Requests

Draft PRs are a valuable tool for teams to collaborate early in the development process and maintain clear differentiation between work-in-progress and ready-for-review pull requests.

heather.hazell
Updated by heather.hazell

Draft & Work-in-Progress Pull Requests in LinearB

Draft (or Work in Progress) pull requests let teams share early work, run CI, and gather feedback before code is truly ready for review or merge. LinearB recognizes these draft PRs so they don’t pollute review and Cycle Time metrics while work is still in progress.


TL;DR — How LinearB treats draft PRs

  • Draft PRs are excluded from Cycle Time calculations.
  • Time spent while a PR is in draft status is counted as Coding Time.
  • Draft PRs do not trigger “Review request hanging” or “Review too long” alerts.
  • Draft PRs are visually marked as Draft on the Branches and PRs pages.
  • For GitHub and GitLab, LinearB uses the platform’s native Draft flag on the PR.
  • Use the advanced naming-pattern settings only if you rely on titles/labels in Azure Repos or Bitbucket instead of a native draft flag.

Supported platforms

  • GitHub – Native Draft PR flag fully supported.
  • GitLab – Native Draft / WIP PR flag fully supported.
  • Azure Repos – Draft PR status is supported via the Azure DevOps API.
  • Bitbucket Cloud – Draft / WIP PRs are supported.
  • Bitbucket Server – Draft PRs are supported starting from version 8.18+.
Important: For GitHub and GitLab, LinearB relies on the repository’s native Draft flag to identify draft PRs. You only need the advanced naming-pattern settings described below if:
  • you are using Azure Repos or Bitbucket and depend on title/label conventions to mark work-in-progress PRs, or
  • your GitHub or GitLab teams choose not to use the native Draft flag and instead rely on title prefixes such as [WIP] or Draft:.

How draft PRs behave in LinearB

Cycle Time & Coding Time

Draft PRs are excluded from Cycle Time calculations. Time while a PR is marked as draft is treated as part of the Coding phase rather than Review or Pickup Time.

Once the PR is switched from draft to “ready for review,” Cycle Time and review-stage metrics start using the PR’s activity as normal.

Notifications & alerts

LinearB suppresses review-related alerts for draft PRs:

  • No “Review request hanging” alerts.
  • No “Review too long” alerts.

This prevents early-stage work from showing up as review risk before it’s ready.

Visual indicators

Draft PRs are clearly marked as Draft on the Branches and PRs pages in LinearB so teams can distinguish work-in-progress from ready-for-review changes at a glance.


Configuring draft PRs in LinearB

For GitHub and GitLab, no extra setup is required—LinearB reads the native draft flag from your Git provider. For Azure Repos and Bitbucket, or if you prefer naming conventions, you can configure naming patterns so PRs with specific titles are treated as drafts.

Global configuration (all repositories)
  1. In LinearB, go to Company Settings → Advanced.
  2. Scroll to the Draft Pull Requests section.
  3. Add regular expressions or naming patterns that indicate draft status, for example: ^Draft:, ^\[WIP\], or DO NOT MERGE.
  4. Click Save.

Any PR title matching these patterns will be treated as a draft, even if the provider does not support (or is not using) a native draft flag.

Per-repository configuration
  1. Go to Company Settings → Git.
  2. Find the repository you want to configure and click the gear icon.
  3. Scroll to the Draft Pull Requests section.
  4. Enter one or more regular expressions / naming patterns that should be treated as draft, for example ^WIP or Draft.
  5. Click Save.

This is useful when a specific repo or team uses different draft conventions than the rest of your organization.

Please note: You typically only need these naming-pattern settings when using Azure Repos or Bitbucket, or when your team chooses not to use the native Draft flag available in GitHub and GitLab, and instead relies on title prefixes such as [WIP] or Draft:.

Best practices

  • Use native Draft status in GitHub and GitLab whenever possible—no additional setup required.
  • Keep naming patterns simple and consistent (e.g., [WIP] at the start of the title).
  • Educate teams that moving a PR out of draft signals it is ready for review and will start counting toward review metrics and alerts.
  • Review draft-detection rules when you adopt new Git providers or change PR title conventions.

How did we do?

Handling Squash Merges in LinearB

Contact