You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pages/guides/maintainers/handbook.md
+15-17Lines changed: 15 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,43 +9,41 @@ This document describes activities performed by a community maintainer, provides
9
9
10
10
## Repositories and projects
11
11
12
-
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:
12
+
Our maintainers work on repositories within the Magento Github organization. Currently, contributions are accepted from the following repositories:
Because most contributions go to the [magento2](https://github.com/magento/magento2) repository, there are several GitHub projects to help manage these contributions.
18
+
There are several GitHub projects to help manage these contributions.
21
19
22
20

23
21
24
-
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.
22
+
Each project has a description of what it does.
25
23
26
24
## Pull requests dashboard
27
25
28
-
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.
26
+
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.
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.
32
+
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.
35
33
36
34
Once you have chosen a pull request, there are some steps to be followed during the review process.
37
35
38
-
### Check CLA and builds
36
+
### Check Contributor License Agreement and builds
39
37
40
-
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.
38
+
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.
41
39
42
-
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).
40
+
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).
43
41
44
-

42
+

45
43
46
44
### Check the pull request target
47
45
48
-
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.
46
+
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.
@@ -69,7 +67,7 @@ If the pull request is not covered by tests, the maintainer should advise the co
69
67
70
68
### Approve changes
71
69
72
-
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.
70
+
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.
@@ -79,9 +77,9 @@ Besides the repositories, projects and code review process, there are other tool
79
77
80
78
### Related pull requests
81
79
82
-
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.
80
+
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.
83
81
84
-
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).
82
+
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).
0 commit comments