Role concept disambiguation

[fyliu]

Meanings

We have a role table, the name for which is probably vague because it can mean different things.

1. project-roles as in roles within a project: PM, Dev, UI/UX, etc.
2. job-roles as in job posting roles: pm, data architect, sw lead, design lead, fullstack dev, backend dev, ui/ux designer, etc.

Here are the tables from the ERD that reference role and what they want out of role:

1. user - desired_roles - roles that the user wants to participate as: PM, full-stack dev, user research, accessibility, QA, mentor(?), etc.
2. recurring_event - roles which should be attending a specific meeting: PM, all, UI/UX, stakeholder(?) etc.
3. win - roles the user participated in: Development, PM, UI/UX, etc. hfla wins
4. permission - role within a project or within the org (since project association is optional): PM, dev lead, design lead, dev, designer, stakeholder(?) etc.

Status

We now separated the job-role meaning into its own set of tables

Questions

1. What should the roles be now?
2. Are there still different meanings of role left?

[fyliu]

Keep in mind we also have the permission_type (relates to permission) table which holds values such as adminGlobal, adminProject, memberProject, memberGeneral, etc.

Maybe some of the role relationships should be referencing permission_type instead. recurring_event(?), permission(?)

[Neecolaa]

Notes from 6-15-23 meeting

1. user - desired_roles - roles that the user wants to participate as: PM, full-stack dev, user research, accessibility, QA, mentor(?), etc.
   1. Free form text field for the user, not related to roles table.
2. recurring_event - roles which should be attending a specific meeting: PM, all, UI/UX, stakeholder(?) etc.
   1. This uses the permission table to determine who is invited to a given meeting
3. win - roles the user participated in: Development, PM, UI/UX, etc. hfla wins
   1. Looks up user's permission record for past roles
4. permission - role within a project or within the org (since project association is optional): PM, dev lead, design lead, dev, designer, stakeholder(?) etc.
   1. Adding a field to permission table for user_defined_title where member can write their own title.
   2. role_id field will be replaced with practice_area_id field.

Roles table will be removed, practice_area will be used instead.

[fyliu]

This is to list the actionable items from above

• create issue to change the user table roles field to be a text field (ERD and SS)
• what to do with recurring_event table?
  • create issue to remove must_roles, should_roles, could_roles fields see comment below
  • add some way to specify filters for permissions records by project, permission_type, practice_area. project is given. Need something to specify permission_type and practice_area. Maybe a permission record that specifies the project, permission_type, and practice_are of the desired attendees. should_permission or something.
• create issue to remove role association from win table
• create issue to add user_defined_title text field to permission table, and replace role_id with practice_area_id
• remove role table
  • the issue has already been renamed to skill: Create Table: skills (formerly role) 😄  #38
  • create issue to remove role table from ERD and SS

[ExperimentsInHonesty]

We are not removing must_roles, should_roles, could_roles fields we are replacing with must should could practice area/permission level

e.g. If you are a Dev with a permission level of lead, then you must attend the DEV Leads/PM meeting

[Neecolaa]

How to best store this information is something we want to discuss with @chelseybeck
Not sure how to store the (practice area, permission level) pair, or if there's another approach that would be better

[ExperimentsInHonesty]

Changes to tables to accommodate removing role as a field name. Issues will need to be made to execute on the following:

1. permission
   1. replace role_id with practice_area_id
2. permission_history
   1. replace role_id with practice_area_id
3. recurring_event (we need to talk to Chelsey for this one)
   1. update name from must_roles to must_attend.
   2. update name from should_roles to should_attend.
   3. update name from could_roles to could_attend.
   4. store value for the attend fields in jason object with the following example
      [{practice_area: engineering, permission_level: practiceLeadProject},{practice_area: pm, permission_level: practiceLeadProject}]
4. user
   1. desired roles is going to change to practice_areas_secondary
   2. replace practice_area_target with practice_area_primary
   3. delete practice area current
5. win (we didnt get to this one yet)
   1. update name from roles to practice area
      1. store value in array

[Neecolaa]

added ERD/SS Adjustment label as well as a comment w/ a to-do list of changes to the table issues that are still open: #22 , #37 , #82

will create update table issues for the already created & closed tables: #14 , #15