Poly Muster scope - Githubissues

Overview

Muster is a simple tool to manage Church services/ministries/events. It was born as an idea to chase two goals:

provide a solution for a problem that I've been having managing my church service with an Excel Spreadsheet.
provide a product/use case to use as a playground to play with different technologies (namely programming language, programming paradigm, data storage, data formats, etc).

This definition is WIP.

Ministry: An umbrella for all related tasks of a specific church capability/service to the wider church community, e.g. Worship Ministry, Outreach Ministry, etc.
Task: A declaration of an action to be done as a part of an Event/Service, for example "Sound", "Projection", "Lightning", "Anchoring", "Worship", "Preaching", "Welcoming", "Cleaning", etc.
Volunteer: An individual who may be in charge of a task on a given date for an event/service.
Team: A grouping of volunteers
Event/Service: A scheduled event composed of a number of tasks executed either in sequence or parallel. i.e. "Sunday Service 1pm", "Women in Action", etc.
Roster: A a list or plan showing turns of duty or leave for volunteers/teams to cater for a Event/Service: next week's Sunday service roster.
User: A Muster user who can be part of a team that has access to application features, i.e a team leader, an administrator, a volunteer.

A volunteer can indicate availability dates
A volunteer can request/approve a roster change
Volunteers can be part of several teams.
Some tasks within a Ministry are in conflict with other tasks for the same Ministry, for example "preaching" is always in conflict with any other tasks (with very few exceptions), therefore a volunteer cannot participate in any other tasks for the same Service within the same event.
Muster automatically generates rosters based on a few rules (e.g. this volunteer is always/never available on the nth week of each month)
Muster can send reminders and calendar invites for volunteers about their roster-ed duties.

Where management means: Create, Read, Edit, Delete (soft), Export the item referred.

Muster data is encrypted in transit and at rest (whenever permanent storage is implemented).

This section here exists solely to list my tech ideas/goals for this playground application.

Use functional programming for both backend and frontend (immutabilty, referential transparency, no exceptions, no nulls, Tagless if possible, etc)
Programming languages: Kotlin, Rust, TS, Scala, Haskell. The first three are the languages I intend to use mainly with the other two as points of reference.
Backend should be a simple Rest API that could evolve to a GraphQL version if it proves to be worth the effort.
API endpoints should be implemented as a function ("Your Service as a Function")
No click ops. Use Dhall for coding OPS/Infrastructure resources.
Use docker, deploy containers if possible ($$$)
Deploy to a cloud provider (perhaps do not use AWS)
Try Github Actions for CI

Backend API in several languages. Compare them and benchmark (desirable)
Front end using a few different frameworks/langs: TS/React, ScalaJs, Elm (optional)
A simple Android app for querying data only (Kotlin or React Native). IOs version is optional.