fix: Adjust GitHub-related Words

communication-and-collaboration.md

@@ -106,7 +106,7 @@ Just like maintainers, most open source contributors are volunteers. They are no
 
 #### Style Guide
 
-You might prefer contributors to add a prefix in brackets to issue and pull request titles. For example, "[Bug]: Documentation link goes to 404 Page Not Found". Or you want them to follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to their commit messages, such as `feat: add new feature for user authentication`. In another case, you might select particular Markdown rules for your project, like one underscore for italics, two asterisks for bolds, etc.
+You might prefer contributors to add a prefix in brackets to issue and pull request titles. For example, "[Bug]: Documentation link goes to 404 Page Not Found". Or you want them to follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to their commit messages, such as `feat: add new feature for user authentication`. In another case, you might select particular Markdown rules for your project, like one underscore for italics, two asterisks for bolds, etc.
 
 Every project has its own convention to keep the consistency around it. So, don't expect your contributors to know what to do when contributing to your project. Consider communicating this in a clear style guide they must follow. You can take an example from GitHub's [style guide](https://docs.github.com/en/contributing/style-guide-and-content-model/style-guide).
 
@@ -124,7 +124,7 @@ You can add a section in your README or contributing guidelines to inform about
 
 #### Timeline
 
-Let your contributors know how long they can expect you to review a pull request or to answer their questions. Inform them if you, for example, won't be available on weekends or after working hours. You can automate this message with GitHub action if you prefer. Read our [Maintainer Power Ups](./maintainer-powerups.md) chapter for more information about GitHub actions.
+Let your contributors know how long they can expect you to review a pull request or to answer their questions. Inform them if you, for example, won't be available on weekends or after working hours. You can automate this message with an action if you prefer. Read our [Maintainer Power Ups](./maintainer-powerups.md) chapter for more information about GitHub Actions.
 
 #### Boundaries
 

glossary.md

@@ -24,13 +24,13 @@ Examples of containerization tools include Docker and Kubernetes.
 
 ## Continuous Integration (CI)
 
-Continuous Integration (CI) is a development approach in which developers regularly merge code into a shared repository. For each change, an automated build and test process is run to detect errors as quickly as possible.
+Continuous integration (CI) is a development approach in which developers regularly merge code into a shared repository. For each change, an automated build and test process is run to detect errors as quickly as possible.
 
 Examples of CI tools include Jenkins, CircleCI, and TravisCI.
 
 ## Continuous Deployment (CD)
 
-Continuous Deployment (CD) is often associated with Continuous Integration and refers to keeping your application deployable at any point or even automatically releasing to production. Continuous Deployment means that every change which passes the automated tests is deployed to production automatically.
+Continuous deployment (CD) is often associated with continuous integration (CI) and refers to keeping your application deployable at any point or even automatically releasing to production. CD means that every change which passes the automated tests is deployed to production automatically.
 
 ## Contributor
 
@@ -71,7 +71,7 @@ Examples of GitHub Actions include running tests, deploying to production, and s
 
 GitHub Discussions are a way to have conversations about your project directly in GitHub. They are a great way to discuss ideas, ask questions, and share knowledge with your community.
 
-## Issue template
+## Issue Template
 
 An issue template is a file that contains a description of the issue you are creating. It is a great way to provide context to your issues and help developers understand what issues you are creating and why.
 
@@ -85,21 +85,21 @@ GitHub has a built-in issue tracker but you can also use other tools such as Jir
 
 ## Linting
 
-Linting is the process of running a program that will analyze code for potential errors. A popular linting tool used frequently is ESLint. You can setup a GitHub action to run ESlint against each pull request that comes in to check for potential errors before it makes it into production.
+Linting is the process of running a program that will analyze code for potential errors. A popular linting tool used frequently is ESLint. You can setup an action to run ESlint against each pull request that comes in to check for potential errors before it makes it into production.
 
 ## Milestones
 
 Milestones are groups of issues that correspond to a project, feature, or time period. You can use milestones to track the progress of groups of issues that are tied to a larger goal.
 
-## Prettier code formatting
+## Prettier Code Formatting
 
 Prettier is an opinionated code formatter that enforces a consistent style for your codebase. You can customize your Prettier configuration to fit your project's needs and customize how you prefer semicolons, single quotes, trailing commas, and more to be formatted.
 
 ## Pull Request (PR) Template
 
 A pull request template is a file that contains a description of the changes you are making to a project. It is a great way to provide context to your pull requests and help reviewers understand what changes you are making and why.
 
-You can also create a GitHub action to respond to pull requests that don't follow your pull request template and urge the contributor to update their pull request.
+You can also create an action to respond to pull requests that don't follow your pull request template and urge the contributor to update their pull request.
 
 ## Release Candidate