Release Notes: Label Guidance for Product Owners

This page explains how Product Owners and Release Managers should use Jira labels to control release-note output. It complements the technical process documented in Release Notes Project.

Why this matters

The release-notes automation generates a first draft from every Jira ticket in a release. Previously, most releases shipped with thin notes or no notes at all — customers and prospects have flagged this as a gap. The automation closes that gap by surfacing work that would otherwise go unmentioned.

The automation classifies each ticket into one of three outcomes:

• Standalone — the ticket gets its own entry under a product area.
• Groundwork for upcoming features — the ticket is bundled into a single subsection with other in-progress initiatives.
• Excluded — the ticket is not mentioned at all.

The default is standalone. Two Jira labels let you override that default. Apply them sparingly and honestly — each labelled ticket is one you're taking responsibility for on behalf of the customer.

The two labels

Label	Effect	Use when…
ExcludedFromRN	Ticket is removed from notes entirely.	You would refuse to tell a customer this shipped.
groundwork-for-notes	Ticket is bundled as groundwork, never shown standalone.	The ticket is part of a larger initiative and delivers no standalone customer value.

info

groundwork-for-notes is part of the planned rollout. Until it is live in Jira, the automation makes a best-guess classification based on ticket text. Once the label exists, Product Owners can apply it to override the automation's guess permanently.

ExcludedFromRN — reasons for exclusion

The bar for this label is high. It removes the ticket from release notes entirely; customers will never see any reference to the work. Apply it only when one of the reasons below clearly applies, and record the reason in the ticket comments so the decision is auditable.

Valid reasons

1. Confidential feature. The feature has not been announced externally and must not be disclosed in public notes. Product Marketing or Legal has said no.
2. Reverted change. The ticket was merged but reverted before the release; there is nothing for customers to observe.
3. Duplicate entry. Another ticket in the same release covers the same customer-visible change and already has (or will have) release-note coverage.
4. Pure tooling or process work. CI, build pipeline, or developer-environment changes with zero customer-observable surface. These are usually caught by the internal-terms filter automatically; use the label as a backup.
5. Security embargo. The security team has requested that the specific fix not be disclosed. Document the decision in the ticket.

Not valid reasons

caution

Do not use ExcludedFromRN for any of these:

• "It's not interesting to customers." If it's genuinely groundwork, use groundwork-for-notes. If it shipped a real change, it belongs in the notes. "Not interesting" is not a reason to hide work.
• "The description is too technical." Rewrite the Release Notes Text field on the ticket. That's the content the automation polishes — better input, better output.
• "It's a minor fix." Small fixes still belong in release notes. A customer hitting that edge case needs to know it's resolved.
• "There are already enough items in this release." Volume is not a reason to exclude.

groundwork-for-notes — when to bundle

Use this label when a ticket is part of a larger initiative and delivers no standalone customer value. The ticket still appears in the notes — customers can see work is in progress — but it is bundled under a single Groundwork for upcoming features subsection with other in-progress initiatives, not given its own heading.

Valid reasons

1. Foundation or scaffolding. Repository setup, module restructure, API stub without callable behaviour.
2. Framework integration without exposed surface. Integrating an orchestrator, library, or service that no customer flow currently uses.
3. Internal refactor or consolidation. Merging modules, moving interfaces, renaming internals.
4. Part of a multi-release epic. The customer value arrives in a later release; this ticket is one of the enabling steps.

Not valid reasons

• "The description is technical." Rewrite the release-note text field instead.
• "It's niche." Niche customer value is still customer value. Leave it unlabelled unless it's genuinely infrastructure.

When to leave a ticket unlabelled (the default)

Leave a ticket unlabelled when it delivers customer-visible value on its own. Examples:

• A new API endpoint customers can call and get a functional response from (even if the capability is specialised).
• A UI change customers will see.
• A bug fix a customer could observe in their accounts.
• A configuration option customers can now set.

If the automation's default grouping is wrong for a specific ticket, submit a ticket to the Technical Writer through the normal process — manual submissions override the automation.

The review process

1. Automation generates a draft per release, split by product area.
2. Each Product Owner receives a review document for their areas.
3. The PO reviews for accuracy and sensitivity, then applies labels where the automation's default is wrong:
   • ExcludedFromRN to tickets that should not be published.
   • groundwork-for-notes to tickets that should be bundled as groundwork.
4. The labels persist on the ticket. Subsequent runs respect them automatically — you are not redoing this work for the same ticket next release.
5. For judgement calls that neither label captures, submit a Technical-Writer ticket through the normal process.

Why we are tightening label discipline

In recent reviews, ExcludedFromRN was applied to a majority of tickets inspected. That signals the label has drifted from "this must not be published" to "this feels uninteresting" — and the result was releases that shipped with almost no notes. The coverage gap is a customer-facing problem, not a housekeeping preference.

groundwork-for-notes is the correct home for uninteresting-because-incomplete. ExcludedFromRN should be reserved for the handful of cases where publishing would be wrong. The Technical Writer will periodically audit ExcludedFromRN usage and challenge tickets that do not meet the bar above.