Suggestion on note taking

### How to manage this issue
- [ ] Read it
- [ ] Make comments or questions on it
- [ ] Check off your name
- [ ] Pass it to the next person
- [ ] Last person, puts it on Product agenda https://github.com/hackforla/peopledepot/issues/28

#### order of people
- [x] Fang
- [x] Nicole
- [x] Chelsey
- [x] Send to product by adding to our agenda

### Details

Hi y'all!

With Bonnie’s help we are quickly prioritizing issues and we’re getting more clarity for a lot of issues, but I wonder if a little bit more notes (especially as it relates to understanding our requirements) could help with everyone being on the same page.

**Suggestion**: Not hoping to make the process more laborious, I personally am noticing a pattern and would like to just propose an idea (or 2) to help make things more clear:

**Reasoning**:
- The `ERD` describes a complex initiative with several user stories and subtasks, and the `PD: Table and field explanations` is providing more details in a spreadsheet format. However, it takes quite a bit of effort (for me, at least) to remember how a table is being used in what scenarios, and oftentimes the spreadsheet also doesn’t have all the details documented. This might also be due to multiple things happening asynchronously and slowly, yet the context for each issue is often different, but it’s not being written in the comments.
- Currently, each table name may not be descriptive enough for us to know the context as it relates to an issue, and the spreadsheet is incomplete. We can certainly remind ourselves to update the spreadsheet, or we can incorporate the following into our comments -- specifically the comments from our meetings with our customers (vrms, CTJ, etc), as we’re talking with their tech leads. _**We can also ask them to provide these things as well.**_

**Suggestion**:
- **_User story_**: adding a couple of sentences to describe a user story within an issue, as we’re going through these issues could help us remember what we’re working towards.
- **_Using table(s)_**: Currently the tables in our ERD seem to be normalized, which is good for database design, but takes some effort to assume the queries or behavior expected, In a way, I might be leaning towards implementing a Backend for Frontend pattern. I believe these tables are also known as look up tables or XREF, or cross reference tables. While XREF is usually meant to increase query speeds, the purpose is much simpler: just to help with understanding. I’m not suggesting we create another database table, but am suggesting a simple spreadsheet table as part of notes and documentation. Please see examples below.

**_An example but using unrelated data:_**

We have ERD (what's on the left), but we don't have the expected data fields (bottom right, which is something similar to the table that I am thinking about, it also doesn't have to be perfect), and eventually, based on what we expect to get, the backend team can help with the actual query (upper right). Even if the frontend is to come up with the query string, knowing the expected fields and data with examples can still be helpful.

**Example 1**: (a simplified example, but maybe not the best example)
- **_User story_**: VRMS manages users, specifically volunteers and admins.
- On app load
- existing users can select a meeting to check-in, or
- check in as new user (gets the eventId from dropdown selector)
- a new user can create new profile
- **_Using table(s)_**:

Story | Scenario 1 | Scenario 2 | Scenario 3
-- | -- | -- | --
State | returning user | new user
Action | Select a meeting to check in | Check in as new user | Create a new profile
Options | All currently available meetings (meetings that are happening right now | Goes to https://www.vrms.io/checkIn/newUser?eventId=641ce82d7e68700019c01849 | Goes to https://www.vrms.io/newProfile
Example 1 | PM/ORG |   |  
Example 2 | ALL |   |  
  | (not sure if it’s behaving correctly) |   |  

**Example 2 (for current issue)**:
- **_User story_**: When a new user signs up (on CTJ's website? or a user can update their info on their profile at anytime on VRMS, which the same data will be used by CTJ's website?), user will fill out his/her/their user profile. We'd expect them to fill out something like the following table.

- Questions to think about:
- Do we need to provide them with every Job_Function category? examples: Design, Research, Engineering, Product... etc
- Is there a better word for this data? `Job_Field` or `Job_Department` or `Functional_Area` or "Competencies"?
- Is the `role` table referring to "Software Engineer" (title) or "Front-end Development" (position / area of responsibility), or "Tech Lead" (leadership)? Note `leadership_type` and `permission_type` and `role` are all each a table.

Here is my current understanding:

I'm imagining: "Fang" who has the `role` of a "Software Engineer", with the `leadership_type` of "Tech Lead" for `project` "PeopleDepot" with `permission_type` "PeopleDepot Admin" will go to "somewhere_page" to enter `user.name_first` and `user.name_last` "Joey Ma" (which will query from all list of users, or all users within `project` "PeopleDepot", and upon selecting this `user` (by `user.id`), Fang can then change my `leadership_type` to "Interim Tech Lead" and `permission_type` "PeopleDepot Admin"...

However, this is more of a guess than an actual understanding of the requirements. Having an actual example would be nice. At this time, I'm actually not quite sure how an "admin user" will be able to assign permission to another user. Someone else could have a different version of what the user is expected to see, select, and enter.

While this user story is not considering quite everything, having some written examples of user stories will help with remembering what the devs are developing for and thereby how to optimize code and db design. The dev team will eventually need some example data to appropriately come up with the each query, and clear up what the best data type to store the data would be.

_some table that helps to illustrate the the relationship_

_Originally posted by @yoyoyojoe in https://github.com/hackforla/peopledepot/issues/142#issuecomment-1483632903_