Update maintainer's handbook to reflect current contribution policies

src/pages/guides/maintainers/handbook.md

@@ -9,43 +9,41 @@ This document describes activities performed by a community maintainer, provides
 
 ## Repositories and projects
 
-Our maintainers work on numerous repositories within the Magento Github organization. The repository that has most activity is [magento2](https://github.com/magento/magento2). Depending on your interest, you might also interact with some of our other repositories, such as:
+Our maintainers work on repositories within the Magento Github organization. Currently, contributions are accepted from the following repositories:
 
--  [pwa-studio](https://developer.adobe.com/commerce/pwa-studio/)
--  [magento2-phpstorm-plugin](https://github.com/magento/magento2-phpstorm-plugin)
+-  [magento2](https://github.com/magento/magento2)
+-  [magento2-page-builder](https://github.com/magento/magento2-page-builder)
 -  [inventory](https://github.com/magento/inventory)
--  [adobe-stock-integration](https://github.com/magento/adobe-stock-integration)
--  and [many others](https://github.com/magento)
 
-Because most contributions go to the [magento2](https://github.com/magento/magento2) repository, there are several GitHub projects to help manage these contributions.
+There are several GitHub projects to help manage these contributions.
 
 ![Repository and Projects](../../_images/repo-and-projects-v2.png)
 
-Each project has a description of what it does. One important project is the **Community Dashboard**, where you can find the pull requests (PR) that will bring most value for the community and will be delivered first.
+Each project has a description of what it does.
 
 ## Pull requests dashboard
 
-Within projects there are pull request dashboards. There you will find our Kanban board, which has columns representing the PR delivery workflow. The columns title are self-explanatory and should represent the action required for the pull requests on that column.
+Within projects there are pull request dashboards. There you will find our Kanban board, which has columns representing the pull request delivery workflow. The columns title are self-explanatory and should represent the action required for the pull requests on that column.
 
 ![pull request Dashboard](../../_images/pr-dashboard.png)
 
 ## Pull request review process
 
-The first step in the review process is to choose and self-assign a pull request from the dashboard. To help maintainers choose a PR to review, there are several labels, the most important being **Priority**. We encourage our maintainers to choose pull requests with the highest priority from the **Community Dashboard** in the **Pending Review** column.
+The first step in the review process is to choose and self-assign a pull request from the dashboard. To help maintainers choose a pull request to review, there are several labels, the most important being **Priority**. We encourage our maintainers to choose pull requests with the highest priority from the **Pending Review** column.
 
 Once you have chosen a pull request, there are some steps to be followed during the review process.
 
-### Check CLA and builds
+### Check Contributor License Agreement and builds
 
-The first thing we encourage a maintainer to check is if the contributor has signed the Adobe CLA. Without this signature, we cannot accept the contribution. If the Contributor has not signed the CLA, that check will be red. Add a comment to the pull request requesting the contributor to sign the CLA.
+The first thing we encourage a maintainer to check is if the contributor has signed the Adobe Contributor License Agreement (CLA). Without this signature, we cannot accept the contribution. If the Contributor has not signed the CLA, that check will be red. Add a comment to the pull request requesting the contributor to sign the CLA.
 
-Once the CLA has been signed, we can check the other builds. Those builds are run based on the contributors pull request and will let us know if the proposed changes are causing existing functionality to break or are not fully compliant with coding standards. If either the Heath Index or Semantic Version Checker fail, the PR should be changed or the proposed changes will need approval by the Adobe team. More information can be found on our [Contributor Guide](../code-contributions/pull-request-tests.md).
+Once the CLA has been signed, we can check the other builds. Those builds are run based on the contributors pull request and will let us know if the proposed changes are causing existing functionality to break or are not fully compliant with coding standards. If either the Heath Index or Semantic Version Checker fail, the pull request should be changed or the proposed changes will need approval by the Adobe team. More information can be found on our [Contributor Guide](../code-contributions/pull-request-tests.md).
 
-![Check CLA and Builds](../../_images/builds-and-checks.png)
+![Check Contributor License Agreement and Builds](../../_images/builds-and-checks.png)
 
 ### Check the pull request target
 
-It is important to ensure that pull requests are targeted to the correct branch. Currently, on the Magento2 repository, we are processing only those PRs that are aimed at the 2.4-develop branch. Please make sure your PR targets this branch.
+It is important to ensure that pull requests are targeted to the correct branch. Currently, on the Magento2 repository, we are processing only those pull requests that are aimed at the 2.4-develop branch. Please make sure your pull request targets this branch.
 
 ![Check pull request Target](../../_images/pr-target-branch.png)
 
@@ -69,7 +67,7 @@ If the pull request is not covered by tests, the maintainer should advise the co
 
 ### Approve changes
 
-Once all the steps above are complete, the maintainer can approve the contributor’s PR. After approving the PR, it will proceed through the delivery process and will be tested to guarantee quality.
+Once all the steps above are complete, the maintainer can approve the contributor's pull request. After approving the pull request, it will proceed through the delivery process and will be tested to guarantee quality.
 
 ![Approve Changes](../../_images/approve-changes.png)
 
@@ -79,9 +77,9 @@ Besides the repositories, projects and code review process, there are other tool
 
 ### Related pull requests
 
-Magento Open source is a complex platform and, some changes may require changes in multiple repositories. For example, if a contributor’s PR performs a change on a feature that is being used on the Adobe Commerce edition, it may require a parallel PR in that repository.
+Magento Open source is a complex platform and, some changes may require changes in multiple repositories. For example, if a contributor's pull request performs a change on a feature that is being used on the Adobe Commerce edition, it may require a parallel pull request in that repository.
 
-In that case, builds need to run using the changes from both PRs. To do so, use the 'related pull requests' feature. This feature is enabled by adding the link to the related pull request on the main pull request description using Github keywords. Details on this are in the [Contributor Guide](../code-contributions/pull-request-tests.md#related-pull-requests).
+In that case, builds need to run using the changes from both pull requests. To do so, use the 'related pull requests' feature. This feature is enabled by adding the link to the related pull request on the main pull request description using Github keywords. Details on this are in the [Contributor Guide](../code-contributions/pull-request-tests.md#related-pull-requests).
 
 ![Related pull requests](../../_images/related-prs.png)