Closed rbommel closed 2 months ago
I agree, that would certainly be handy! There's already an issue requesting just this, actually: https://github.com/DavidCain/mitoc-trips/issues/11
I don't think my thoughts have changed a ton since that thread. I'm open to the idea of calendar integration, but it would require a lot of new data collection & added complexity. We already have a MITOC calendar (that's public) where many events are posted by hand. For events with very clear start/end and location (e.g. office hours, visiting speakers, etc.) the calendar is reliably updated.
Some thoughts on the general idea of making a calendar integration:
The problem (in my mind) is how to handle the notions of a trip "start" and "end." There was an intentional choice to keep the datetime management on trips really simple: every trip just has a start date, with no concept of a start or end time. In fact, some trips may even span multiple days.
My understanding of the ICS format is that each entry would be required to have a start and end. We could use the Google Calendar notion of "all-day events" (where there's no display of a start or end time, even though internally it's just midnight to midnight). However, I fear that even that representation would be misleading when some events are (for example) full weekend trips that span two days!
Now, we absolutely could try to start requesting a start and end time from trip leaders, but that opens up a whole other can of worms:
I think it would make sense to just put the trip as full day events in this calendar. Fiddling around with times for this would be way too much work and not very useful. Sure, multiday backpacking trips might show up as one day events in the current system where there is no trip end date, but that is already the case in the trip listing anyway, and people will still read the trip listing before signing up. Trips in other time zones seem extremely rare. If the leader doesn't change the date, there is currently no way to know that. I think that that is a separate problem (which may cause some problem with the automatic trip reporting to the MIT admin, not sure...).
The idea of this proposal is to have another way to see the trips that are happening and to save Mike the trouble of copying trips by hand to the calendar. I would not necessarily propose to put this together with the office hours in the general MITOC calendar, but to make another colour for it, like we have for Camelot and Intervale already.
If other people have thoughts on this, feel free to comment!
If the leader doesn't change the date, there is currently no way to know that. I think that that is a separate problem (which may cause some problem with the automatic trip reporting to the MIT admin, not sure...).
I think trip dates changing entirely is very rare, and people normally edit the trip if that happens. The trip reporting to MIT admin goes off a different set of data -- we request that leaders give an itinerary shortly before their trip. The itinerary includes free-text fields for when they'll start hiking, rough return time, etc. By asking right before the trip starts, we increase the likelihood of the itinerary remaining accurate. Sadly, none of this data would be helpful for calendar events, since it's approximate free-form data and people would want to know start/end times well in advance.
The idea of this proposal is to have another way to see the trips that are happening
I can certainly respect the convenience of a calendar, but it's worth noting that we already have RSS, a weekly digest email, the trips page, and people sending announcements to mitoc-announce.
to save Mike the trouble of copying trips by hand to the calendar
Is somebody already hand-copying most trips to a calendar? On the official MITOC calendar, I do see some trips, mostly things like the Camelot birthday party and regular Yoga sessions (it's worth noting that Yoga has a precise start time & a location... might be a bit confusing if we also had a separate calendar that listed it as an all-day event)
Trips in other time zones seem extremely rare.
Yes, extremely rare. But that's the nature of edge cases -- if you write a feature, you've got to handle those edge cases. My preferred mentality is generally to avoid getting too fancy, so I need not handle edge cases at all. 😄 Were somebody to give the start time to an event in a different timezone, we probably don't want the calendar reporting the wrong times! (Though I think we avoid this problem entirely by just declining to request start & end times at all).
It could be useful to have an ics feed of the trips on top of the RSS feed that already exists, as ics can be imported into Google Calendars.