====== Calendar Software Comparison ======

===== Goals and desired features =====

  * Anyone can create an event.
  * Locations have at least a date, time, description, location, and tags.
  * A tagging mechanism which allows restricting tags to specific individuals.
  * Ability to import events from other calendars (okay if it requires custom code).
  * Ability to embed calendar in other websites.
    * Must be able to filter the embedded view to specific tags or locations.
  * Visually cohesive with the OrcasHub ecosystem (okay if it requires some CSS work).
  * Excellent mobile experience.
  * Nice to haves
    * Somewhere that events can be discussed or people can express planning to attend.

===== Existing options =====

  * OrcasHub native
    * Pros
      * High level of familiarity with code. Comfortable adding new features.
      * Highly integrated into OrcasHub already. Unified user and permission model.
      * Nice visual experience of viewing events by week.
      * Supports consuming events externally via RSS.
      * Excellent mobile experience.
      * Already has years of familiarity within the community.
    * Cons
      * Single developer currently. Though the code base is pretty simple.
      * Changes will be limited to Tony's availability until we find someone else to help.
      * This also means changes will also take time from other aspects of OrcasHub
    * Missing features
      * Tags on events (small)
      * Limit tags to specific individuals (small)
      * Filtering of events by tag or location (medium)
      * Embedding externally (medium, depending on desired layout)
      * Discussion (likely by integrating with Discourse) (medium)
      * ActivityPub (??)
  * Gancio
    * Pros
      * Third-party developing gets us a starting point for free.
      * Has extremely basic event recurrence already.
      * Has basic support for embedding (though it's unclear if the embedded layout is desirable).
      * Has nice search functionality.
    * Cons
      * Changes that the upstream project doesn't agree with will have to be maintained as a fork.
      * Changes that the upstream doesn't want to prioritize will be limited to our ability to learn Vue, Nuxt, and the other tools used. (Tony doesn't have experience with these tools).
      * Using a [[https://v2.vuetifyjs.com|deprecated UI framework]].
      * Separate authentication/users. Does not support being an Oauth client (this seems to be prioritized work -JV)
      * Main page user experience is visually overwhelming and may need to be replacing.
    * Missing features
      * Limit tags to specific individuals (unknown, but involves logic and db changes)
      * Undesirable main page UI may need to be replaced (very large)
      * Discussion (likely by integrating with Discourse) (medium)
  * Mobilizon
    * Pros
    * Cons
      * Ugly af.
      * Probably buggy af.
      * Major usability/bugginess in limited testing.
    * Missing features

===== Other Considerations =====
  * What could John spin up to modify more easily?
  * What could another engineer spin up to modify more easily?
  * How amenable is Gancio team from making modifications?
  * How easy are PRs to get incorporated into the main project?
  * Could a strategy be to integrate Gancio, but minimize dev (Tony) changes until we have a set up (announcements, photos, etc) in place with other elements?