Events: Incremental approach

Updated almost 8 years ago by Jon Engelbert
After reflecting on my experience so far working on the 'new' events schema, and also upon my conversation with Sam yesterday, I'm feeling that small incremental changes are the best way forward.  

Fundamental Pain:
- The user cannot edit an upcoming event when it is part of an event series.  I.e., for a weekly meeting on websiteone, the product manager may want to set an agenda and publish it so that other developers can view it and decide whether to attend.  Or the event organizer may want to change this event instance's time,  but not that of the entire series.

Why is it 'fundamental'
- This is an infrastructure challenge... i.e., there is presently no way to represent an instance of an event series before it is instantiated as a hangout.
- It's related to one-time Event instance creation.  I.e., which model should be used for the upcoming one-time event?  If we use the Hangout model to store upcoming instances of repeating events, then does it makes sense to also use it to store upcoming one-time events?  In that case, do one-time events need to refer back to the "Event" model?  
- This is related to a new Events Index view that shows upcoming and live events.  How will we generate a collection of all event instances for this new Events Index view?  Presently, we only look in the Events model to get upcoming events.  Will there be redundancy if we add it event instances from  Hangouts?

Proposed Solution:
- The simplest solution given the existing code is to extend the hangouts model so that it includes the full life-cycle of the event instance.  Presently, the Hangouts model only models live and past events.  
- The "Event" model can be an abstract Event Series, i.e. it includes the event schedule and template and it's only purpose is to generate event instances (i.e. Hangouts).

Issues that need to be resolved as part of the solution:  
- We don't want to create and store upcoming event instances for every instance of a series ...especially if the series never ends.  Instead, we need to lazily create upcoming event instances. 
- With lazy instantiation, the event instances will be instantiated on the fly as needed. So we need to remove the event instance from the schedule if the event instance is persistent (i.e. saved to the database as an upcoming Hangout).   The schedule, with its 'removed' instances, will need to be persistent.

Interdependencies with other user stories:
- This should be resolved/implemented before related features such as the new Events Index page, and before the capability to invite users to an event or to allow users to rsvp to an event, and before adding tags and resources to the Events, in order to avoid the need to revise the code for those features.

comments powered by Disqus