Review and update github access for read/write/maintainers

[edwinjue]

Overview

We need to clean up the GitHub team permissions on this project, so that everyone has the appropriate level of access.

Action Items

• Open the roster (resource 1.01.01)
• find a row that is blank in column M
• click on the link in column L (same row)
• annotate what you find
  • If user is on read and write team, add the following text to column M
  • if user is on write team and not on read team, add to read and the following text to column M

  write
  

  • user is on read team but not on write team, add to read and the following text to column M

  read
  

  • if user is on neither team, add the following text to column

  none
  

• view the roster by inactive (resource 1.01.02)
• look up each GitHub username on the write team, and if there, remove them update the value in column M to "read"
• Add to agenda for review with org rep

Resources/Instructions

• 1.01 311-data team roster
  • 1.01.01 311-data team roster, Permissions to update and document filter
  • 1.01.02 311-data team roster, inactive filter

Teams

• 311-data
  • 311-data-write
    • 311-data-maintainers
      • 311-data-admin

Permission Rules

breakdown of who should be granted access to the three tiers of permissions for our repo:

Details by team

311-data (read access):
All users (should include ex-311 data members, if removed from write/maintainers, make sure to add them here)

311-data-write:
All active 311 participants marked active as per roster (may need to update who is active/inactive on roster as well)

311-data-maintainers:
(this is different from being a maintainer on another GitHub team e.g., write-maintainer, read-maintainer, which enables you to add and remove people from the team)
Confirm with @ExperimentsInHonesty (Bonnie) to determine who should still be here no one, we don't use this team, but we are leaving it for now

311-data-admin:
One PM (so that they can edit issue templates), possibly the tech lead if they need it for something specific like setting up branch protections. Permission should be removed when they no longer need it.

[ExperimentsInHonesty]

@ryanfchase I audited your teams and roster and added some new columns. So this instructions above are out of date. Please fix and let's make sure onboarding and offboarding issues have action items related to keeping this update

What I did

• I removed the column that said what permission people had
• I added or updated unique columns for
  • Check Read team (has a URL that you can click on that looks up that member on the read team)
  • Read Team (Boolean and you have to fill it out)
  • Check Write team (has a URL that you can click on that looks up that member on the write team)
  • Read Team (Boolean and you have to fill it out)
  • Hack for LA GitHub member (Boolean) - this column was already there, I just updated it
  • Check for Public (has a URL that you can click on that looks up that member to see if they have their membership marked public)
  • Public/2FA is now only Public (many choices)
    • yes (if it is public now)
    • no (if it is not public, and they are inactive so it's too late to ask them)
    • NO, please fix (if they are active, send them the URL and ask them to change it)
    • not a member of github.com/hackforla
    • not a valid GitHub handle
    • unknown, since the GitHub handle is missing in column J
• I checked each person, updated all their GitHub info (which teams they are on and if they have their membership marked as public).

What I did that requires you to do something

• I created an Active members - missing info tab for you, which lists all the active team members that are missing info on the roster. Please get them to fill it out.
• Only one of your members does not have a LinkedIn on the roster. He indicated he is looking to career transition to software. Please ask him for his LinkedIn: Johnny Wu
• Update your onboarding and offboarding issues to have steps where you check to see if new members have filled out everything in the roster, and marking the permissions as TRUE TRUE TRUE for adding to write team, read team and that they are in our GitHub.

[ExperimentsInHonesty]

and p.s. this is why everyone cannot be assigned to the same issue. Everyone is assigned so no one pays any attention.

[ryanfchase]

• ETA for completing draft: Friday 2025-02-07
• ETA for completing ticket: Sunday 2025-02-09

[ryanfchase]

Needing to punt this a little further down. ETA 2025-02-12. I do have a question for org rep tho:

• Q: is this meant to live as an Ongoing ticket, and we pass the ticket around between PMs (and include this in our pre-meeting checklist)? If so, what size should it get?