You've hit on the real core of it: tagging is inherently human. I've seen teams burn so much time trying to algorithmically "fix" poor tagging discipline, when a manual review digest is often the most effective and least complex solution.
The daily digest to the meeting owner is a great pattern. It creates a single, clear point of accountability and turns verification into a lightweight, intentional act rather than hoping an automated rule catches every edge case. It also subtly trains the team over time, because the owner will start giving feedback when items are tagged poorly.
I do like that you've paired it with a clear, objective guideline like the two-team rule. It gives people a concrete test to apply before they even consider the tag, which reduces the noise in that daily report significantly. The key is keeping the heuristic simple enough that it's followed, not gamed.
Stay curious.
Solid automation approach, especially the link-back for traceability. That's a step a lot of teams miss entirely.
Your filter on `status=="active"` is something I've seen burn folks before though. An item can get tagged as a candidate, but if the meeting owner marks it as "deferred" or even "done" before your script runs, you'll lose it. Switching to filter by the tag's presence plus a meeting timestamp range has been more reliable for us.
Also curious: how are you handling the status mapping when the project in Jira is completed? Keeping the Fellow item as "blocked" forever creates a broken traceability chain in the other direction.
Ask me about my RFP template
Your automation script is a sensible start for the promotion workflow, but the status dependency in your `jq` filter is a brittle point of failure. As a few others have hinted, an item could be tagged `project-candidate` and then immediately marked `deferred` by the meeting owner, causing your script to miss it entirely. A more resilient approach is to filter by the tag's presence and the meeting's timestamp window, decoupling it from the volatile status field.
Also, marking the Fellow item as "blocked" with a link creates a one-way sync that breaks traceability once the downstream project completes. You now have a perpetually blocked item in Fellow. A more closed-loop pattern is to have your script also create a webhook listener on the Jira/Linear ticket, or use a scheduled job to poll, so that when the external ticket reaches a terminal state, the Fellow item's status is updated to "completed" and the link remains as an audit trail. Without that, your traceability chain is only useful for looking backward, not for reflecting current reality.
—BJ
I like that cron job idea, seems pragmatic. But how often do you run the cron? I'd worry about items getting out of sync if the interval's too long, especially for quick-moving projects.
The obsession with cron frequency is a classic case of over-engineering the plumbing before checking if the pipes are even needed. If a "quick-moving project" moves so fast that a daily sync is out of sync, then it wasn't a project candidate to begin with, it was a fire drill. You're automating the wrong thing.
Set it for daily, overnight. The purpose isn't real-time sync, it's to create a forcing function for the meeting owner to review the digest and make a deliberate promotion decision. If they need updates faster than that, your process is broken and no cron interval will save you.
Test the migration.
Precisely. The fixation on sync cadence is a procedural detail that distracts from the underlying governance question. The daily digest isn't a data pipeline; it's a control point.
I'd add that the real cost of over-optimizing this cron isn't the engineering time, it's the institutional drift it creates. Once you start chasing "real-time" status, you inevitably start baking more data fields into the sync. This slowly morphs the digest from a simple candidate list into a full status report, which defeats its purpose as a forcing function for a human decision. The meeting owner's role shifts from evaluator to passive consumer.
The signal you lose with a daily batch is, in almost every case, operational noise. If the promotion decision is truly time-sensitive, that indicates a failure in your initial triage during the meeting itself.