Feature suggestions for my productivity app

I am building a product that basically logs everything you do on your machine for work and at the end oif the day you just have to approve it and then it will go and sit under your ticket on JIRA. I wanted to understand if you were a user of this product, 1. what are some features that would be a deal breaker for you? and 2. how much would you pay for this product per month?

Any response would be helpful, thanks

reddit.com
u/Akarsh_Hegde — 5 days ago
▲ 2 r/learnrust+2 crossposts

How do you handle write-side reconciliation across multiple issue trackers in Rust? (idempotency + partial failure)

I want to read tasks from a bunch of trackers (Jira, Linear, GitHub Projects, Azure DevOps, Asana, Trello) into one canonical model, and the read side is mostly solved. The write side is where I keep getting bitten.

The problem: a single logical update on our end: say "move this task to In Progress and reassign", fans out into N tracker-specific mutations, each with different semantics. Jira wants a workflow transition (you can't just set status), Linear takes a typed state ID, Azure DevOps wants a work-item patch document, Asana has its own section move. Each can independently succeed or fail, and most have no transactional wrapper. So I'm left with the classic distributed-write mess: how do I make the fan-out idempotent, and what do I do when mutation 3 of 5 fails after 1 and 2 already committed?

What I've looked at:

  1. Outbox + per-tracker reconciler loop: Write intent to a local table, a worker drains it per tracker, retries on failure with backoff. This is the obvious answer and probably where I land, but it pushes the whole problem onto "is this mutation idempotent on retry?" and for some trackers I can't get a stable idempotency key, so a retry risks a duplicate transition or a double comment.

  2. Saga / compensating actions: Define a rollback for each forward mutation so a partial failure unwinds cleanly. Feels correct in theory, but writing a faithful inverse for "transitioned a Jira workflow" is genuinely hard, workflows aren't always reversible, and the compensation can itself fail. Starts to feel like more machinery than the problem deserves.

  3. Just make every write last-writer-wins and reconcile on next read: Simplest, and tempting for a local-first tool where the canonical state lives on-device anyway. But it papers over real divergence, if the remote write silently failed, the user thinks the board is updated when it isn't.

For the Rust folks who've built something like this: is the outbox-reconciler the consensus answer, and if so how are you getting idempotency for APIs that don't hand you a key? Or is there a pattern I'm missing that sidesteps the per-tracker inverse problem? I'd rather not reinvent a wheel if there's a crate or an established shape for this.

(Context for disclosure: I'm building Meridian, a local-first dev-worklog daemon, so this write path is something we ship, not a toy.)

reddit.com
u/Akarsh_Hegde — 6 days ago

Would you use this if it helps you out in maintaining your worklogs for you as well?

Building a developer efficiency tool that runs locally on your machine and keeps track of where you are spending your time, understands what you do and keeps your project management tool up to date for you
Check it out and star the repo: https://github.com/Meridiona/meridian
Mac desktop coming soon!

reddit.com
u/Akarsh_Hegde — 7 days ago
▲ 2 r/Asana

Is there an open-source tool that normalizes tasks across Jira / Linear / GitHub Projects / Azure DevOps / Asana into one canonical model?

We integrate with a bunch of issue trackers and I'm trying to avoid reinventing a wheel that surely exists somewhere.

The problem: every tracker has its own task shape. Jira has workflows + custom statuses, Linear has typed states, Azure DevOps has work-item types + board columns, Asana has sections, GitHub Projects has whatever fields you bolt on. We need to read tasks from all of them and treat them uniformly downstream — same status semantics, same hierarchy (epic → story → subtask), same notion of "assignee," same "is this done?" check.

What I've found so far:

- OSLC — the actual open standard for this (OASIS, RDF/Linked Data). Looks right on paper but adoption is thin; none of the SaaS trackers expose native OSLC endpoints, so you're writing adapters anyway. Feels heavyweight for what I need.

- Commercial CDM tools — Planview Hub (ex-Tasktop), Unito, Exalate. They clearly nailed the "map each tool once to a canonical model" pattern (O(N) adapters instead of O(N²) pairwise syncs), but they're closed-source and priced for enterprise.

reddit.com
u/Akarsh_Hegde — 8 days ago
▲ 10 r/Linear+2 crossposts

Is there an open-source tool that normalizes tasks across Jira / Linear / GitHub Projects / Azure DevOps / Asana into one canonical model?

We integrate with a bunch of issue trackers and I'm trying to avoid reinventing a wheel that surely exists somewhere.

The problem: every tracker has its own task shape. Jira has workflows + custom statuses, Linear has typed states, Azure DevOps has work-item types + board columns, Asana has sections, GitHub Projects has whatever fields you bolt on. We need to read tasks from all of them and treat them uniformly downstream — same status semantics, same hierarchy (epic → story → subtask), same notion of "assignee," same "is this done?" check.

What I've found so far:

- OSLC — the actual open standard for this (OASIS, RDF/Linked Data). Looks right on paper but adoption is thin; none of the SaaS trackers expose native OSLC endpoints, so you're writing adapters anyway. Feels heavyweight for what I need.

- Commercial CDM tools — Planview Hub (ex-Tasktop), Unito, Exalate. They clearly nailed the "map each tool once to a canonical model" pattern (O(N) adapters instead of O(N²) pairwise syncs), but they're closed-source and priced for enterprise.

reddit.com
u/Akarsh_Hegde — 8 days ago