Minor updates

These are minor changes in response to the code review for this PR>

Author: cabutlermit

basics/github.md

@@ -6,7 +6,7 @@ As of 2025, the GitHub Organization [MITLibraries](https://github.com/MITLibrari
 
 There are only two "owners" of the GitHub Organization: the team lead for EngX and the team lead for InfraEng. All other user accounts in the GitHub Organization are "members."
 
-Additionally, all of the repositories have been updated to ensure that the right times have the right access to the right repositories. In general, this means that infrastructure repositories have the [InfraEng](https://github.com/orgs/MITLibraries/teams/infraeng) team with the built-in **maintain** Role, the data engineering repositories have the [DataEng](https://github.com/orgs/MITLibraries/teams/dataeng) team with the built-in **maintain** Role, and the discovery/ui/web repositories have the [EngX](https://github.com/orgs/MITLibraries/teams/engx) team with the built-in **maintain** Role.
+Additionally, all of the repositories have been updated to ensure that the right teams have the right access to the right repositories. In general, this means that infrastructure repositories have the [InfraEng](https://github.com/orgs/MITLibraries/teams/infraeng) team with the built-in **maintain** Role, the data engineering repositories have the [DataEng](https://github.com/orgs/MITLibraries/teams/dataeng) team with the built-in **maintain** Role, and the discovery/ui/web repositories have the [EngX](https://github.com/orgs/MITLibraries/teams/engx) team with the built-in **maintain** Role.
 
 Member accounts **do** have the right to create new repositories. Once they create a repository and configure it with the [Recommended repo settings](#recommended-repo-settings), they should notify at least one of the Organization owners who will then set up the rest of the collaboration permissions.
 
@@ -40,7 +40,7 @@ In most cases, [GitHub flow](https://guides.github.com/introduction/flow/) will
 
 Ideally, feature branches should encompass small, targeted changes. Keeping your work focused will mean fewer merge conflicts. When building a new code base this may not always be possible, but what you want to try and avoid are long running branches. By the time you want to merge, the distance between your feature branch and main will usually mean a lot of conflict resolution in your future.
 
-There is an exception to this for Infrastructure code. For the Terraform code, InfraEng uses a Simplified Git Flow model (which could also be seen as GitHub Flow on steroids). In this case, each deployment environment (dev, stage, & prod) is linked to a long-running branch in the repository. The `dev` branch is the working branch for all changes/features. PRs and code reviews are required for any merges to `stage` and the only merges to the `main` branch come from approved merges on the `stage` branch. More details on this model can be found at [Simplified Git Flow](https://medium.com/goodtogoat/simplified-git-flow-5dc37ba76ea8) and at [Simplified Git Flow for InfraEng](https://mitlibraries.atlassian.net/wiki/spaces/IN/pages/2920480769).
+There is an exception to this for Infrastructure code. For the Terraform code, InfraEng uses a Simplified Git Flow model. In this case, each deployment environment (dev, stage, & prod) is linked to a long-running branch in the repository. The `dev` branch is the working branch for all changes/features. PRs and code reviews are required for any merges to `stage` and the only merges to the `main` branch come from approved merges on the `stage` branch. More details on this model can be found at [Simplified Git Flow](https://medium.com/goodtogoat/simplified-git-flow-5dc37ba76ea8) and at [Simplified Git Flow for InfraEng](https://mitlibraries.atlassian.net/wiki/spaces/IN/pages/2920480769).
 
 ## Merging and Rebasing