Generate a Weekly Changelog from Jira Without Status Meetings
A Jira changelog requires exactly three deterministic filters: resolution date, project key mapping, and issue type categorization. Here is how to automate release notes from Jira without meetings.
Soobrief Team — Product & Engineering, Sooapps ·
In short
A reliable Jira changelog requires querying issues by resolution date (`resolved >= -7d AND statusCategory = Done`), mapping Jira project keys to product areas, and categorizing issues by issue type. Once this deterministic pipeline is established, weekly release notes are generated automatically without manual compilation or status meetings.
A reliable Jira changelog requires querying issues by resolution date (resolved >= -7d AND statusCategory = Done), mapping Jira project keys to product areas, and categorizing issues by issue type. Once this deterministic pipeline is established, weekly release notes are generated automatically without manual compilation or status meetings.
Engineering organizations spend hours every Friday copy-pasting ticket keys and summaries from Jira into Slack channels, Google Docs, or email newsletters. Because Jira workflows differ wildly across squads, manual summaries inevitably suffer from missing tickets, inconsistent technical jargon, and delayed delivery.
Step 1: Establish the Completion Timestamp Filter
In Jira, an issue marked as complete must have a populated resolutiondate. Relying on custom status names (such as "Verified", "Ready for Prod", or "Live") breaks whenever a team modifies its board workflow.
The definitive JQL query for a weekly cadence uses the Jira status category rather than individual status names:
project in (CORE, WEB, API)
AND statusCategory = Done
AND resolved >= startOfWeek(-7d)
AND resolved < startOfWeek()
ORDER BY resolved DESC
| Filter Dimension | Optimal Jira Field | Why It Matters |
|---|
| Completion State | statusCategory = Done | Custom status names vary, but Jira normalizes all terminal steps into the Done category. |
| Time Boundary | resolved >= -7d | Tracks actual shipment date rather than the ticket creation or update date. |
| Scope Boundary | project in (...) | Limits ingestion strictly to customer-impacting software repositories. |
Step 2: Deterministic Mapping from Jira to Product Updates
An LLM should never be permitted to guess which feature belongs to which department. Categorization must follow deterministic rules configured by engineering leads:
- Project Key → Product Line:
WEB maps to "Dashboard & Web App", API maps to "Platform & APIs", and IOS maps to "Mobile Client".
- Issue Type → Update Category:
Bug maps to "Fixes & Reliability", New Feature and Story map to "New Capabilities", and Task maps to "Under the Hood".
- Labels & Epics → Sub-grouping: Epics provide broader narrative context, while labels like
security or performance ensure critical work is highlighted.
Jira Issue (WEB-1422: "Fix CSRF token expiry on OAuth callback")
├── Project: WEB ────────────► Surface: Web App
├── IssueType: Bug ──────────► Category: Fixes & Reliability
└── Resolution Date: Sept 8 ─► Window: Week 36
Step 3: Webhook Ingestion and Historical Backfill
Jira supports Atlassian Connect, OAuth 2.0 (3LO), and standard webhooks.
- Historical Backfill: Upon initial connection, a paginated search (
/rest/api/3/search) scans the last 14 to 30 days of completed issues, building the historical baseline.
- Real-Time Webhooks: Jira fires
jira:issue_updated payloads. The ingestion worker checks changelog.items for transitions into statusCategory = Done, recording the completion event idempotently in PostgreSQL.
When Friday afternoon arrives, all completed tickets are already indexed, deduplicated, and organized by product area. The team only reviews a coherent, pre-drafted narrative instead of hunting through Jira boards.