DEV Community

Chris Fenning
Chris Fenning

Posted on

Improve the chance your feature gets prioritized Example #79116

#productivity #writing #tutorial

Why read this post? If you want the business to prioritize your feature or suggestion, you need to do more than write a kick-ass JIRA ticket.

This post uses a real JIRA ticket as an example of how to increase the chances someone in the business will pay attention to it.*

It includes a summary of the issue with the current ticket, then gives an updated description that fixes the issue.

At the end, there are suggestions for how to further improve the ticket's chances of prioritization.

The goal is not to make people feel bad about the ticket's they've written. The goal is simply to help improve a ticket and give it the best shot at being read, understood, and prioritised by the business.

This is not a guarantee, other things like budget and priorities will have an impact. But this will definitely improve the chances.

JIRA Server suggestion #79116

What’s the issue with the description?

There is nothing in the ticket to show a quantified value to either the business or to the user for making this change. If the process for prioritising this ticket involved anyone from the business, there isn’t an obvious reason why it should be picked.

What to change?

The Description should be updated to include a clearer justification for why this suggestion should be prioritized.

Suggested description update:

What's happening: From Jira Software 10.5 onwards, the “Email notification character change limit” feature limits the diff calculation in email notifications to 10,000 characters by default. When exceeded, users receive a generic message stating “there are too many changes to display” instead of the actual content difference.

Impact / Problem:
While the character limit prevents performance delays in the outgoing mail queue, it also creates issues with communication and workflow for teams that rely on email notifications for issue tracking and audit purposes.

  • Users who depend on detailed change logs in emails lose visibility into what was actually modified.
  • Manual review time increases because users must open Jira and compare changes directly in the issue.
  • This reduces trust in email notifications and slows down review and approval processes.

Proposed Change (Technical Summary):
Add an administrative option to disable or bypass the character difference check entirely, or to configure it per project or user preference, so teams that need full visibility can opt in.

Expected Benefits (Business Outcomes)

  • Improves efficiency for teams that rely on email-based review workflows
  • Reduces time spent manually verifying issue changes in Jira
  • Inc reases user satisfaction and confidence in notification

Technical Summary
From Jira 10.5 (JRASERVER-65963 fix), the outgoing mail queue is single-threaded and can get delayed when calculating differences between original and new content.
To mitigate this, Jira introduced a character limit (default 10,000) for calculating differences. When exceeded, the email shows “there are too many changes to display” instead of the diff.
Administrators can change the limit using the jira.email.diff.max.characters system property, but there is currently no option to disable the check completely.

Steps to Reproduce

  1. Set up SMTP outgoing mail and notification scheme for “Issue Updated” or “Issue Commented.”
  2. Create a new issue and add a comment (notification is triggered).
  3. Edit the comment and add content exceeding 10,000 characters.
  4. Email notification displays “there are too many changes to display” instead of showing the diff.

Workaround
Increase jira.email.diff.max.characters to a higher number.
However, this only partially resolves the issue and can reintroduce mail queue delays.

What else can be done? to improve this ticket?

To strengthen the business case, the ticket submitter could include any of the following details:

  • User Impact Scope: How many users or teams rely on email notifications for detailed change tracking (e.g., QA teams, auditors, external clients)?
  • Business Context: Is this issue affecting internal users only, or also external stakeholders (e.g., vendors, customers)?
  • Quantifiable Impact: Do you have any estimate of extra time or steps added due to missing change details (e.g., “adds 5–10 minutes per issue review”)?
  • Environment Type: Is this occurring in a regulated or high-audit environment (e.g., finance, healthcare, government) where missing change data poses a compliance concern?
  • **Performance Impact Evidence: **Are there any metrics showing that increasing the limit (e.g., to 20,000 or 50,000) does not cause significant mail queue delays?

Top comments (0)