Automated Catalog Maintenance

[ewega]

As a team member
I want catalog population and updates to be automated
So that manual maintenance is minimized and regular team rituals encourage review and presentation of new IP:

The team discussed automating lifecycle management for catalog assets, including sending notifications to owners when their IP has not been updated for a set period (e.g., three months), prompting them to review and update the content. 1
The process would involve tracking asset status (work in progress, ready for catalog, deprecated) and using labels or metadata to manage this. 2
Owners would receive reminders (such as email or issue creation) to check if their asset is still relevant or needs updating, ensuring the catalog remains current. 3
The approach aims to minimize manual maintenance and keep the catalog accurate, with the responsibility for updates resting on asset owners. 4

Technical Requirements

I couldn’t update the issue due to a tool error. If you want me to retry adding the plan to the issue, please confirm and I’ll proceed.

Here’s a detailed plan you can add to issue #11:

Research summary (concepts to leverage)

• Lifecycle metadata & ownership: track asset status (WIP/Ready/Deprecated) and owner contact in front‑matter or a catalog metadata store.
• Staleness policy: “stale after N months” with reminders, escalation, and eventual deprecation.
• Automation hooks: scheduled checks via GitHub Actions + notifications (issue creation, email, or Slack).
• Human review loop: recurring team ritual for review/demo of newly updated assets.

Proposed plan

1) Define catalog metadata & lifecycle

• Add/standardize metadata fields for each asset (front‑matter or data file):
  • owner (GitHub handle/email)
  • status (wip, ready, deprecated)
  • last_updated (ISO date)
  • review_due (computed or stored)
• Document lifecycle rules in a short CATALOG_LIFECYCLE.md:
  • When assets move between statuses
  • Update expectations and responsibilities

2) Choose automation mechanism

• Use GitHub Actions on a scheduled cron:
  • Parse catalog metadata
  • Identify assets stale beyond threshold (e.g., 90 days)
  • Notify owners
• Notification methods (pick one or multiple):
  • Create GitHub issues assigned to owners
  • Post to team Slack (webhook)
  • Email (if supported/allowed)

3) Build the staleness detection workflow

• Implement a script (Node/Python) to:
  • Read all catalog entries
  • Compute “stale” based on last_updated
  • Generate a report artifact (CSV/JSON)
  • Trigger notifications

4) Automate reminders & escalation

• First reminder: when stale threshold reached
• Second reminder: 2–4 weeks after first
• Escalation: notify team lead or apply needs-review / stale label
• Auto‑deprecate after 6 months stale (optional)

5) Update catalog UI/UX (optional)

• Display status and last_updated in catalog
• Add badges for stale/needs-review
• Filter by status or review due date

6) Team ritual integration

• Monthly/biweekly review:
  • Review new/updated assets
  • Confirm deprecations
  • Celebrate new IP entries

7) Rollout plan

• Phase 1: metadata standardization + documentation
• Phase 2: staleness script + scheduled workflow
• Phase 3: notifications + team ritual
• Phase 4: optional UI enhancements + escalation

8) Success criteria

• ≥90% assets have owner, status, last_updated
• Automated reminders sent on schedule
• Reduction in manual catalog maintenance effort
• Regular review cadence established

---

If you confirm, I’ll retry adding this plan directly to issue #11.