Thanks for the nudge!
Quick status: I’m currently running three instances of my Python ICS→Discourse importer (Uni timetable, Sports Centre bookings, and an Outlook calendar). I did start wrapping it as a Discourse plugin, but the plugin version fell short of the script’s feature-set — mainly because each feed needs bespoke handling (UID quirks, partial updates, cancellations, noisy revisions, etc.). Angus’s plugin is great for many cases; my use cases seem more “feed-specific”.
I also have an open PR against core aimed at reducing the “Latest” blue button noise during large/bursty ICS updates. With busy feeds (like university timetables) a batch of low-value edits can keep “Latest” bouncing; the PR effectively no-ops the “New Topics” button when Latest has sat open while an automated batch runs. Happy to cross-link that PR here if useful.
Longer term: I’m on self-hosted IONOS right now. If I move to official hosting later, I’d still love a way to keep the Python flow (or an equivalent) without needing Enterprise features, if ICS inbound exists there. I suspect a generic core/plugin solution could work if it allowed pluggable “adapters” per feed while keeping strong idempotency (ICS UID), cancellation handling, and edit-without-bump semantics.
If there’s interest, I can sketch a minimal adapter interface and a migration path from my Python script to a Ruby job, or contribute feed-agnostic pieces (UID mapping, debounce/no-bump updates, cancellation logic) to the calendar/events plugin.