search

hasgeek / funnel

Website for hasgeek.com
https://hasgeek.com/
GNU Affero General Public License v3.0
46 stars 52 forks source link

Provide vCal calendars for entire site and per-profile #533

Open jace opened 4 years ago

jace commented 4 years ago

Project schedules currently offer an iCal export, but there is no provision for a site-wide calendar or a profile-specific calendar. These are missing features and should be added.

Considerations:

  1. Due to the number of sessions available, these calendars should only be blocks indicating the start and end times for the entire project, not per session. This can use Project.schedule_start_at and Project.schedule_end_at.

  2. Should past projects be included? This has the obvious problem of calendars growing with time even if past events are uninteresting. Should we offer choices of calendar, like upcoming vs archive?

jace commented 2 years ago

Additional considerations:

  1. A project may have multiple blocks of back-to-back sessions where the blocks themselves are several days apart. This has happened with projects that have been reused to host weekly or monthly sessions. A block is not a primary data model, and is inferred from the timestamps of sessions. This inference is currently used only for the project starting notification and is implemented in the Project.starting_at classmethod (introduced in #857). There is no other conception of a block in the existing code and data model.

  2. Using Project.start_at and Project.end_at is not sufficient because it will span all such time blocks and will appear to be a continuous multi-month event when a project has been reused. (These new start_at and end_at columns are cached from schedule_start_at and schedule_end_at and were introduced in #1114, after this ticket was originally opened.)

  3. That PR also introduced the concept of projects without sessions, meaning we can no longer rely on the Session model to find the list of sessions. We must also find Project instances that have no Session linked to them, an expensive query.

  4. A site-wide calendar is hard to implement because there is no spam control. It is possible to do per-profile calendars (subject to the above challenges), but for a group of profiles, we need a grouping criteria: either the (temporary) verified flag on profiles that controls homepage listing (a hacky fix for spam control) or a newer topic-tag grouping (subject to #1421).

Possible approaches:

  1. Define a block of sessions as a primary data model, but backend-only, auto-calculated from Session and Project. This could either be a materialized view or an outcome of SQL triggers, or in-app logic. These blocks are still linked to a project and not a profile, and so could have overlaps. However, it should be possible to export all blocks linked to a profile into a calendar entry.

  2. Treat the calendar as also being a primary data model so that cache refresh is not as expensive. Given the overlap with block of sessions, this could be the same table, but it may be separate tables to reflect their cross-purposes: blocks are affiliated with source projects, while calendars with their consumers.

jace commented 2 years ago

Alt approach: the calendar simply has everything in the Session table, including sessions that are five minutes long and contain "break" or "introductions". This is noise in the content, but is technically simpler as there is no need to define the new block-of-sessions model.

For projects without sessions, a second query is used to find them and add them to the calendar.

sankarshanmukhopadhyay commented 2 years ago

A "site wide" perspective which is being discussed is creating a method for any visitors to hasgeek.com to access a calendar of all events coming up and being able to download a file to add to their calender should they be technically capable.

Some sites do this with a calendar embedded - the management of the calendar being handled internally through access management for CRUD.

As a visitor who wants to know what upcoming events are of interest to me - I'd like to see a schedule of events and optionally a method to register interest to participate.

jace commented 2 years ago

Problem: any spammer can create an event and publish it, and many do, advertising everything from dental appointments to escort services. How do we exclude these from the site-wide calendar? What is the inclusion or exclusion criteria?

sankarshanmukhopadhyay commented 2 years ago

Problem: any spammer can create an event and publish it, and many do, advertising everything from dental appointments to escort services. How do we exclude these from the site-wide calendar? What is the inclusion or exclusion criteria?

I'm not sure how the CRUD flow is now at Hasgeek. My assumption of the web calender is that it is an asset to which access is limited to a project management role at Hasgeek (ie with the @hasgeek.com domain) and events published are limited to ones where sign up is available.

jace commented 2 years ago

My assumption of the web calender is that it is an asset to which access is limited to a project management role at Hasgeek (ie with the @hasgeek.com domain) and events published are limited to ones where sign up is available.

Issues:

  1. Anyone can list a project that accepts sign-up.
  2. If the calendar is populated from existing projects, there has to be a well-defined constraint on which projects are eligible. This is the main pending requirement before we can implement anything.
  3. OTOH, if the entries in the calendar are separate from projects, there is the workflow problem of keeping data in sync when there are schedule changes or cancellations. From past experience, whichever item is not a priority for the team will get ignored and get stale, so there should be a single source of truth.
jace commented 2 years ago

Implementation on this issue is stuck until there is clarity on where the data is coming from. @sankarshanmukhopadhyay @zainabbawa

sankarshanmukhopadhyay commented 2 years ago

Implementation on this issue is stuck until there is clarity on where the data is coming from. @sankarshanmukhopadhyay @zainabbawa

The possible sources of data

It would seem like unless a way to prevent undesirable entries into the calendar from SPAM at hasgeek.com is designed the most practical approach is not going to be possible. Perhaps the hasgeek.com --> calendar publishing workflow could have have only allowed users/accounts to post. Not sure.

jace commented 2 years ago

We do have mechanisms for allow-listing:

  1. Only projects from verified profiles are listed in the calendar. Verified profiles are a temporary mechanism for allowing listing on the home page.
  2. Only projects featured by site editors are listed. Featured projects appear in the spotlight banner on the home page.
  3. A new Topic classifier (from #1421) can replace the verified profile mechanism (as a seamless migration when it happens).
sankarshanmukhopadhyay commented 2 years ago

We do have mechanisms for allow-listing:

Which approach would the product want to go with?

jace commented 2 years ago

Depends on what the calendar is for. There seem to be multiple variants of this requirement:

  1. A user wants to build their own calendar of interesting events and wants to integrate it with their native calendar app (phone/desktop)
  2. A user wants to share such a calendar (with abuse potential similar to Twitter lists).
  3. The platform wants to introduce new users to activity via a curated calendar.
  4. Internal logistics team wants to keep a heads-up of their own commitments (a variant of user sharing in 2).
  5. Internal sales team wants to make a showcase for sales prospects (variant of either 2 or 3).
sankarshanmukhopadhyay commented 2 years ago

Depends on what the calendar is for. There seem to be multiple variants of this requirement:

1. A user wants to build their own calendar of interesting events and wants to integrate it with their native calendar app (phone/desktop)

2. A user wants to share such a calendar (with abuse potential similar to Twitter lists).

3. The platform wants to introduce new users to activity via a curated calendar.

4. Internal logistics team wants to keep a heads-up of their own commitments (a variant of user sharing in 2).

5. Internal sales team wants to make a showcase for sales prospects (variant of either 2 or 3).

See https://github.com/hasgeek/funnel/issues/533#issuecomment-1250932710

A "site wide" perspective which is being discussed is creating a method for any visitors to hasgeek.com to access a calendar of all events coming up and being able to download a file to add to their calender should they be technically capable.

This is a display shelf equivalent of "come, walk in - we have a lot of things going on". The display shelf will for now also be able to meet the point you raise in (5)

jace commented 2 years ago

Which brings our choices down to one of:

  1. Profiles (brands) are allow-listed (how TBD) and all projects under this profile will appear in the calendar. This requires no maintenance effort beyond including a brand, but it will also foreground low quality or niche projects within these profiles.
  2. Individual projects that are featured are included in the calendar. This becomes an ongoing effort where each project must be approved by a site editor, but offers fine grained control.
  3. Hybrid: projects from 1 are auto-included but can be removed, while projects from 2 are explicitly included or removed by a site editor.