That’s a good question, Nathan — and I think there’s definitely space for a minimal, feed-agnostic approach that could live either as a small extension to the Calendar/Event plugin or as a lightweight core job.
For a PR to be generally useful, the key seems to be making the importer adapter-based rather than feed-specific. Something like:
- Each feed defines a small adapter (could be Python, YAML, or Ruby) that maps ICS fields → Discourse topic fields (
title,body,tags,start,end,location, etc.). - Core handles idempotency (
UID↔ topic ID mapping), cancellation (STATUS:CANCELLED), and quiet edits (update without bumping Latest). - Plugins or site settings could configure polling interval, tag mappings, and bump policy (
always,never,on major change).
That way, institutions with noisy or complex feeds (university timetables, room bookings, Outlook calendars, etc.) can provide an adapter suited to their data without hardcoding anything in core.
If there’s interest, I’d be happy to outline that adapter interface or prototype the core “ICS upsert” helper as a Ruby job that others can build on — so that this can gradually evolve from standalone Python scripts to something maintainable and generic within Discourse’s ecosystem.