u/dannyt74

Hi,

I got messaged by a bot from Boardy.ai after a post on X. I followed up and even joined an Google Meet with the Bot. 😄
Before I commit to its Pro plan I would like to know if anyone here already used it and what your experiences are. Is it worth it or are there better offerings.

Thanks,
Danny

Hi,

I got messaged by a bot from Boardy.ai after a post on X. I followed up and even joined an Google Meet with the Bot. 😄
Before I commit to its Pro plan I would like to know if anyone here already used it and what your experiences are. Is it worth it or are there better offerings.

Thanks,
Danny

Hi,

I got messaged by a bot from Boardy.ai after a post on X. I followed up and even joined an Google Meet with the Bot. Before I commit to its Pro plan I would like to know if anyone here already used it and what your experiences are. Is it worth it or are there better offerings.

Thanks,
Danny

This is a summary of their blog post on how they assigned owners to over 14,000 internal repos when as of early 2025, less than half had a clear owner. It became a problem during a secret-scanning remediation push. they could rotate a leaked secret, but without knowing who owned the repo, doing so was risky and there was no way to route the work.

Their old model only tracked ownership for repos backing a deployed service, through an internal Service Catalog. That covered maybe a third of repos. Everything else, team repos, docs, internal tools, one-off projects, personal experiments, had no owner on record. Finding one meant checking commit history, reading the README, or asking around in Slack.

What they built:

Two GitHub custom properties: ownership-type (Service Catalog / Team / Individual) and ownership-name (free text, validated against actual org membership, team existence, or Service Catalog entries).

Before asking a single person to do anything, they synced ownership from the existing Service Catalog, which auto-covered about 1,500 repos.

For the rest, they ran a GitHub App on a Kubernetes CronJob that opened an issue on unowned repos with a 30-day deadline, then archived anything still unclaimed. They picked archiving because it's reversible, repo goes read-only, Actions stops, nothing gets deleted.

Two incidents:

1. They archived a repo that had a Datadog integration configured to open issues in it. Datadog couldn't create the issue post-archive, and nobody had been directly notified about the pending archival, their own monitoring paged the owning team before the ownership system did. Fix: they started @-mentioning repo admins directly and assigning all write-access users as a fallback.
2. They realized a stale or corrupted response from Service Catalog could trigger mass-archiving of repos that actually had valid owners. So they added a threshold check. If a single run is about to archive or flag more repos than some conservative limit, it aborts and pages instead of running.

End state: ~3,000 active repos, ~11,000 archived (up from ~3,000 archived at the start), done in under 45 days. They also tightened the ongoing enforcement loop from a 30-day grace period down to one hour, and made ownership required at repo creation going forward.