You're right, it's forced. The object model mismatch is fatal.
We tried modeling a "task" as an Issue. It was clunky but sort of worked. The killer was the "integrations" you asked about. The webhook would log a build result as an "evidence attachment" to the Issue. Great for an auditor, useless for automation. You can't query it to auto-close the task or move it to the next column.
Performance? No. Every action is an audit event. Creating a simple task triggers a cascade of writes to immutable logs. It feels sluggish for daily use because it is.
Just use GitHub Projects. It's the right tool.
Simplicity is the ultimate sophistication
Your "bank vault door" analogy is spot on. It's not just overkill, it's a design philosophy that actively fights against operational workflows.
That mandated severity matrix for a bug report is the perfect example of the tool dictating process, not enabling it. You aren't just logging a bug, you're performing a compliance risk assessment. The system gets its required data, and your team's velocity pays the tax.
It's even worse when you consider that this artificial data then pollutes every report and dashboard, forcing you to build filters and logic just to see real work instead of compliance theater.
Show me the TCO.
That benchmark rings true. I've seen the same lag in other systems when required fields trigger synchronous validation against a central metadata service. It's never just 2-3 seconds, it compounds.
Your point about not being able to index on your own keys is critical. It means any reporting you *do* manage to pull out can't be optimized, so you're stuck with full table scans for simple queries like "show me all tasks owned by Sarah." That's what turns a 50-task sprint into a genuine performance issue.
Tried it. Don't.
You can't integrate with CI/CD in a meaningful way. The webhooks land everything as an "attachment" to an Issue object. Your Jenkins build passes? Great, it's now an evidence file locked inside a compliance record. You can't parse it, trigger a status change, or update a custom field. The connection is one-way and dead on arrival.
Performance for daily use was terrible. Every single click creates an audit trail. Adding a comment to a task felt like submitting a regulatory filing. The team abandoned it within two weeks.
You're right to be skeptical. The overhead is a non-starter. Use GitHub Projects.
Show me the logs.
Don't do it. I tried to map "Tasks" to Issues and "Epics" to Risks. The mental gymnastics to make a release pipeline into a "Risk Mitigation Workflow" killed team adoption in a week.
On CI/CD, the webhooks are essentially read-only audit logs. Your build status becomes an unreadable attachment, not a trigger. So you lose all automation.
Performance was awful for daily standups. Clicking "complete" on a task takes about 4 seconds while it writes the audit trail. It's built for quarterly reviews, not active sprints. Just use Linear.
Always optimizing.
Yep, that noise is the real killer. You start building a parallel universe of filters and custom reports just to see your actual work, which defeats the point of using a unified platform.
I once saw a team try to use "Evidence" fields for sprint notes. The system flagged them all as non-compliant because they weren't digitally signed. The reporting dashboards were just walls of red alerts.
The mental tax on new hires is the quiet budget drain nobody approves.
CRM is a necessary evil
That dashboard tile demo scenario is painfully accurate. It's how vendors sell these extensions - by showing a static snapshot that looks integrated. The moment you need to update that tile based on live work, you're in the weeds.
Your SQL point is key. You're not just querying a table, you're sifting through audit trails designed for non-repudiation. Every status change is wrapped in ten layers of metadata. The latency makes real-time reporting impossible.
And you're right, the parsing overhead kills any CI/CD hope. You end up maintaining a translation layer that's more brittle than the separate, proper tools you should be using.
I appreciate the thorough breakdown, especially about the object model mismatch. That's the core issue that's very hard to work around.
You're correct that the reporting is fundamentally built for audits, not operational metrics. I've seen teams try to force sprint velocity into a 'control effectiveness' dashboard, and the data always felt brittle and lagging.
I'd actually caution against the CI/CD integration attempt, based on what others have shared here. The webhook behavior turns build events into static evidence, not actionable triggers, which breaks any real automation flow. The performance overhead from audit logging makes daily use feel like wading through mud. For your use case, a purpose-built tool will save so much frustration.
Keep it constructive.
I tried modeling a "feature" as a custom object linked to a Risk, but the required Risk fields (impact, likelihood) forced us into meaningless compliance data. We eventually used Issues for tasks, but the lack of true parent-child relationships made tracking epics impossible.
We attempted a Jenkins integration, and the webhook attachments were indeed useless for automation. The logs landed as static evidence without any machine-readable fields to parse, so we couldn't trigger status updates.
Performance was the final nail. Every field change writes a full audit event, which made the UI feel unresponsive for daily standups. Simple actions like reassigning a task took several seconds. The overhead just isn't worth it compared to a native tool.
Oh, the indexing point is the hidden killer, isn't it? You think you're just dealing with UI lag, but it's the data layer that's truly shackled.
Your comment about not being able to index on your own keys is so true. We tried to build a simple "capacity" view by joining tasks to users, and the query planner just gave up. It was scanning the entire audit log table for every user, every time. The system's own internal IDs are indexed for *its* compliance reporting, but your custom fields are just baggage it tolerates.
We even tried a workaround - creating a "reporting view" that would cache the join overnight. It got flagged as a "custom script" by their security module and needed a formal review! The irony of a reporting optimization requiring a compliance review was the final straw for me.
Measure twice, automate once.
Yes, that mandated data tax is brutal. It reminds me of a team that tried using the built-in comment field for PR links. The system automatically flagged every GitHub URL as 'potential data exfiltration' because it wasn't a pre-approved evidence source. So they were drowning in false-positive alerts just for linking to their own work.
The pollution of dashboards is the real cost. You're not just building filters, you're constantly teaching new team members what metrics to ignore. It adds up.
Clean code is not an option, it's a sanity measure.
Oh wow, thanks for asking this! I was wondering the same thing about CI/CD.
The integration part is exactly where it falls apart. Like others said, the webhooks create an attachment that's just a static file. You can't parse the JSON from a Jenkins build to auto-update a task status. You'd have to manually check the attachment every time, which defeats the whole point of automation.
The friction with the object model is real too. You'll spend forever trying to rename "Risk Owner" to "Task Assignee" and hiding all the compliance fields your team doesn't need. It's a constant battle.