Reviewing PR suggestions
Once a repository is connected, every PR your team merges into the release branch is classified and proposed as a Dev Item. You’ll find these proposals in the Suggested Dev Items section on the Dev Items page.
This page covers what you’ll see there and how to act on it.
Where suggestions appear
Section titled “Where suggestions appear”Open Dev Items in the main navigation. Above the list of tracked Dev Items there’s a collapsible section labeled Suggested Dev Items. It’s expanded by default whenever you have one or more pending suggestions.
Each suggestion in the list shows:
- Title — pulled from the PR title, with any conventional commit prefix (
feat:,fix:, etc.) stripped off. - Type — feature, improvement, or bugfix. Other types don’t appear here (see How PRs are classified).
- Repository and PR number — so you can click through to the original PR on GitHub.
- Suggested release date — the moment the PR was merged.
- Linked tickets — any Linear or Jira ticket URLs that VEKTIS detected in the PR description, up to ten.
Promoting a suggestion to a Dev Item
Section titled “Promoting a suggestion to a Dev Item”When a suggestion is something you want to measure, promote it.
-
Click “Promote” on the suggestion line.
-
Review the prefilled fields. A dialog opens with the title, description, and linked tickets already populated from the PR.
-
Add the measurement details VEKTIS needs. These are the fields that aren’t in the PR:
- Target metric — the metric you’re trying to move (e.g. signup conversion rate).
- Target impact — the change you expect (e.g. +5%).
- Target direction — whether higher or lower is better.
- Owner — who’s accountable for measuring this Dev Item.
- Initiatives (optional) — group this Dev Item with related work.
-
Save. The Dev Item is created in Planning status with a link back to the original PR. The suggestion disappears from the Suggested Dev Items list — its status changes to Promoted.
The new Dev Item is identical to one you’d create from scratch. From here, follow the normal flow: add baseline measurements, mark as released when ready, and start collecting post-release metrics.
Dismissing a suggestion
Section titled “Dismissing a suggestion”Dismiss a suggestion when it’s a PR you don’t want to track — for example, an internal tooling change that wouldn’t show up as a measurable customer outcome, or a fix that’s too small to merit its own metric.
-
Click “Dismiss” on the suggestion line.
-
Confirm. The suggestion disappears from the list.
Filtering by status
Section titled “Filtering by status”By default, the Suggested Dev Items section shows only Pending suggestions — the ones still waiting for you to act on them. To see what’s already been handled, switch the status filter:
- Pending — waiting for you to promote or dismiss.
- Promoted — already turned into a Dev Item. Click through to the linked Dev Item.
- Dismissed — already dismissed. Visible for reference; not actionable.
What happens behind the scenes
Section titled “What happens behind the scenes”You don’t need to think about this, but if you’re curious:
- A merged PR appears as a suggestion within a minute or two of the merge being recorded on GitHub.
- If the same PR is reopened and merged again, the existing pending suggestion updates with the new title and description. Already-promoted or already-dismissed suggestions are not re-created.
- Disconnecting the GitHub integration does not remove existing suggestions — they remain in your Suggested Dev Items list. Only new merges stop being added.
Related
Section titled “Related”- How PRs are classified — why some PRs become suggestions and others don’t.
- Creating and Managing Dev Items — the standard Dev Item lifecycle.
- Collecting Baseline Data — the next step after promoting a suggestion.