Project Roadmap
mirdaki opened this issue · 0 comments
This should help plan and explain the features and work that needs to be done for the project. It's a more organized and focused version of the use cases issue. It is a living document, so the specifics and goals will change overtime.
Goals
The back-end exists to do three things for the club:
- Be the single source of truth for club information (that the website, Discord bot, etc, can reference and use)
- Automate away recurring management tasks
- Reduce our dependencies on proprietary software and external services
Version 0.X
The code base has grown a bit, so it's probably best to do a little bit of refactoring and reorganizing.
Grouping items like member.rs and event.rs in something like a models folder, as well as separating out authentication stuff and other similar items will help to make navigating the code easier.
I also heavily suggestion using dependency injection (pass in things like the database connection as an argument instead of creating it in every database call). This will reduce some redundancy and make it easier to test without needing a database (by using some sort of mocking framework).
Related issues:
Version 1
The first release of the back-end should be focused on letting members easily sign in to meetings (so we wont need to use a Google form anymore).
Members should be able to go to the club website (at ufopensource.club/signin) or be able to use another client (like the Discord bot). Members don't have a traditional account (with username and password) so we only need to accept their UFL username. Once we receive the sign in, we can verify that there is a meeting going on (or is close to a meeting) and that they have previously provided other information like their GitHub handle (or have explicit chosen not to provide it). A response is sent back letting them know if it was successful and if they should provide more info. This website page follows this flow.
To achieve this, we need the following REST queries to work:
- Officers can authenticate themselves and CRUD events
- Officers can authenticate themselves and CRUD members
- Members can sign in to events
- Members can fill out their own info (but only once to reduce possibility of abuse. After that it will require an officer to modify things)
Version 2
Automated event management and syncing with external sources (Google Calendar, Facebook, Discord bot), should be the next focus. This will help to reduce the load on the Social Chair, so they won't need to worry about making multiple posts for the same event or manual adding them to the back-end.
I feel like a good architecture for this would be to have a few bots and chron jobs for each of those services run independently of the back-end. They would use the REST APIs to authenticate (just like every other client or user), so the code doesn't become too tied with any one service.
Features associated with this:
- Google Calendar
- Pulls in event changes from Google Calendar (including title, location, description, times, etc) into the database
- Pushes event changes from the database (including title, location, description, times, etc) into the Google Calendar
- Resolves inconsistencies between the database and Google Calendar
- Facebook
- Allow social chair to authenticate and set event announcement text and posting times for each event (or use a global schedule for posting)
- Facebook bot creates and shares events on Facebook according to schedule
- Facebook bot updates events on Facebook based off their information from the database
- Discord
- Allow social chair to authenticate and set event announcement text and posting times for each event (or use a global schedule for posting)
- Discord bot creates and shares event announcements on Discord according to schedule
Version X
From here it's hard to see where the best use of time is. We've discussed project management, back up plans, expense tracking, documentation hosting, meeting notes, and plenty more. Tackle whatever will help the club the most.