Closed starbelly closed 3 years ago
How would the notifications be handled?
As discussed on Slack, I would be for using a github repo to store the reports and manage versionning and interactions inside the board with it. This allows us to maintain one source of truth in term of storage but also prvide for free a ticketing system and versionning using git. Also we shouldn't store a report in the db but as a separate file/object so it can be reused by any other tools. So I would suggest the following implementation, maybe more simpler and that can be reused:
The general sense of it is to use a solution that allows us to handle interactions over the reports without too much custom tooling. I don't think we should re-invent a ticket system :) Also we can reuse such pattern for our own request board, to handle support requests from the members. This can eventually be reused by other groups for their need. We cna for example expand it for the stipends.
Thoughts?
How would the notifications be handled?
notifications can be handled the way they are for mail for members and soon events. We just use the fastmail smtp server to send out emails.
As discussed on Slack, I would be for using a github repo to store the reports and manage versionning and interactions inside the board with it. This allows us to maintain one source of truth in term of storage but also prvide for free a ticketing system and versionning using git. Also we shouldn't store a report in the db but as a separate file/object so it can be reused by any other tools. So I would suggest the following implementation, maybe more simpler and that can be reused:
I definitely don't disagree there should be less custom tooling. My concern is around time. Specifically, trying to make the below work would take more time that just making a table in the database. However, the interface(s) will basically be the same. As such, we can try the route you suggested and time box it to a day. If for some reason it becomes problematic then we could fallback to using a table in the database. Thoughts?
EDIT: Note we have to move working groups and volunteers to the database devoid of this. To be clear.
@benoitc As discussed at today's meeting we will MVP this with simply providing an upload report button to chairs on the site vs building a full blown user interface to github. Then we can discuss later how we want to iterate this.
EDIT: Board members will have to communicate with chairs about the report (if necessary) via email for the time being.
Here is how I think this should generally be implemented:
What's up in the air is where to put the reports while they are private and being collaborated on. There are two forms of storage we could leverage :
A private github repository. Only board members would have access to said repository. This makes sense except that chairs won't be able to collaborate on the document. We could pull the document in via the api, and submit changes, etc. This is going to get really hacky though I do believe and does not support comments, etc.
Abstract schema:
working_groups
working_group_volunteers
is_chair (boolean)
working_group_reports
board_members
The above can be augmented easily at a later point time. It could facilitate ad-hoc reports to the board.
Normally, I would not suggest such de-normalization but we are wanting to keep this as simple as possible. Likewise, we should not aim for perfection. Good enough is the goal here. Make it work! ™️