Maria Reisinger _MetaFrazo_ Community Champion

Thank you so much, @Anwesha Pan ! That means a lot, especially coming from someone who knows this community so well. Looking forward to connecting and learning from you along the way. 😊

Thanks for kicking this off, @Adithya Ramesh. Not an admin myself, so I'll leave the tiers to the people who earned them. Your three questions stuck with me, though: all of them sit before the change lands. @Viswanathan Ramachandran's point about post-implementation evidence suggests a fourth one: once a change is live,…

Thank you, David. The line in 2.7 I would underline for regulated customers: coordinated behavior only shows up when events are correlated. Once write tools are introduced as described in 2.5, the events that matter most sit in Jira itself: a status changed, a field edited, a work item closed. On the customer side of the…

Jimi, one answer to your question from the governance side, though Aqib may have his own: in many setups the work type decides which workflow applies, and with it which controls. A Change that becomes a Task can skip an approval step entirely, without anyone breaking a rule on purpose. So even if blocking every path isn't…

Thanks Birkan, the Lead Time vs Cycle Time comparison is the part I'll remember. "Waiting to start, not being worked on" is a useful way to tell a backlog or approval delay apart from an execution problem. One question: how does the field handle an issue that gets reopened? Does the time after reopening add to the same…

Great thread. @SPHIOR's point deserves more attention than it's getting: the audit log tells you that something changed, not what it contained. That's the gap that decides whether delegation is safe. We ran into exactly this building event-based change tracking for Jira. The native audit log is a list of "someone touched…

The framing I keep coming back to is your last line, that backup protects the schema and governance protects it from becoming something you don't recognize. That distinction gets collapsed constantly, and the two need completely different answers. One thing I'd add to the quarterly audit. Your four questions all describe…

The step-shape list is the useful part. Most pricing coverage stops at the table. One thing I keep thinking about after the audit: you fix the top three, and then what? Rules drift the same way schemes do. Someone widens a JQL, someone adds a branch, and the shape you fixed in October is a different shape by February.…

@Mia Tamm _Simpleasyty_ your example lands, and I would like to build on one part of it. The idea that an answer should carry its own reasoning is the strongest trust signal in this thread for me. It does come with a precondition though: the relationships that reasoning rests on have to be correct. "Superseded by", "owned…

I think this would also improve governance and consistency. Once organizations start using dedicated workflows for different idea types, the workflow effectively defines the lifecycle of each idea type. It makes sense for status groups to automatically follow that lifecycle, especially when a view is already filtered to a…

Solid breakdown, and the line about object counts not being enough deserves to be repeated more often. One thing I would add to the evidence section: the history that existed before the migration. Schemas and objects arrive, but the record of who changed what and when in the source system is often what a reviewer asks for…

Thank you, @Sami Shaik. This is exactly the kind of response I was hoping the article would provoke. "Narrate, not decide" is a wonderful way to compress it. It draws the line precisely where I think it belongs. Let the generative part draft, summarize and comment, but keep the state changes, meaning the transitions, the…

This really resonates, especially the line that visibility is not governance. The dashboard tells you what an application consumed, but it does not decide who should have access, what counts as abuse or what budget is acceptable, and that gap is exactly where the real work sits. I keep seeing the same pattern one level…

Really insightful article. I particularly like the distinction between navigational and behavioural complexity. One thing I’d add is that behavioural complexity isn’t static. Every workflow change, new automation, app installation or process adjustment can gradually increase it. The real challenge isn’t just auditing…

Absolutely. In my experience, Jira itself usually isn’t the problem. Complexity grows as more teams, workflows, approvals, automations, and dependencies are added over time. Small configuration differences can gradually turn into operational blind spots. The real challenge is often visibility. If you can’t see where…

Thank you, @Lukasz Modzelewski! 😊 I'm honored to be part of the authors' club and grateful for such a warm welcome. Looking forward to contributing, learning, and growing together with this amazing community! 💙

Interesting perspective. I particularly like the shift from looking at totals to looking at patterns. I think the same principle applies beyond worklogs. Individual events rarely tell the full story. Whether it's worklogs, workflow activity, or configuration changes, it's often the patterns over time that reveal where…

Great checklist. I also see these platform changes as a good opportunity to review workflow governance. Major migrations often don't create inconsistencies, they simply make existing ones much more visible. It's a great time to step back and ask whether workflows are still consistent and maintainable across projects.

Thanks, @Dave Mathijs! Glad it resonates. On the Icon URL: as far as I know, that's a leftover from older Jira versions, where each status had a small icon displayed next to it in the issue view. And I'd sign your lozenge wish immediately. More colors for statuses, but keeping the categories at exactly three. That's the…

I agree @Viswanathan Ramachandran. An unassigned issue definitely needs attention. But first, teams need visibility. If you can't see where issues are getting stuck or why they stay unassigned, it's hard to improve the process.

I like that your checklist focuses on the governance side, not just the archive action itself. One thing I keep thinking about: the checklist isn't usually the difficult part. The difficult part is applying it consistently across dozens or even hundreds of Jira projects. At that scale, visibility becomes the real…

Field documentation is only half the battle. The other half: tracking when fields change and how they're used over time. That's where admins go blind. A custom field breaks in prod, and suddenly nobody has visibility into what went wrong. That's why I love Jared's approach with Assets and 90-day audits. MetaFrazo does…

Great thread. Most tools (and the REST-diff script @s_gridnevskii describes, which is a solid low-cost start) answer the question "has the state changed since my last baseline?" That proves drift happened. But I keep thinking about the questions this doesn't answer. When an auditor asks "who changed this, and when?", a…

Great thread! Reading this from a compliance angle: the "Permission Helper doesn't see properties" point stands out to me. It means access restrictions can exist that no standard tool surfaces. For regulated teams that's an audit question waiting to happen: "who could move issues out of 'In Approval', and since when?"…

Thanks, Davit. I think that's an interesting perspective, especially for organizations that use Jira for resource management. At the same time, I see it a little differently. For many organizations, Jira has evolved far beyond being just a task tracker. It's where work actually happens. That's one of the reasons I find it…

That's a great point. Right now, Jira essentially offers two states for custom fields: active or deleted. There isn't really a lifecycle state like "retired" or "do not use." Many teams work around this by renaming fields to something like [Deprecated] Customer Impact or ZZ_Do_Not_Use_Customer_Impact, removing them from…

Thanks for sharing your process. Starting with classifying fields instead of immediately deleting them makes a lot of sense. "Delete, consolidate, keep, needs further review" feels much more realistic than trying to clean everything up in one go. I completely agree that stakeholder alignment is essential. Technical…

Hi Bill, thanks for the reminder and sorry for the late reply. The content and experience are my own. I do use AI tools to help polish my English writing, and I'll disclose that going forward. Noted on the guidelines, appreciate the pointer

Thanks @Peter Norris , that describes the pattern really well: the governance layer ends up living in Confluence, maintained by hand, and slowly drifting away from what's actually in Jira. Your point about not duplicating information is important. The moment you copy field facts (screens, projects, usage) into a page, you…

Great question, @Luke Gackle . And @Shawn Mathias is right. This is technically solvable with field contexts: same field, different option sets per project or issue type. But that's exactly where the governance question starts. Contexts solve the configuration problem and quietly create a semantic one: the same field name…