DevFW-CICD/ingress-nginx-helm
14
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add some information about triaging pull requests (#7822)

Browse source
This commit is contained in:
Noah Ispas 2021-10-19 15:52:39 +02:00 committed by GitHub
parent 5a52d99ae8
commit abb05135bb
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 31 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
CONTRIBUTING.md
View file

@ -34,7 +34,9 @@ All changes must be code reviewed. Coding conventions and standards are explaine
### Merge Approval
Ingress collaborators may add "LGTM" (Looks Good To Me) or an equivalent comment to indicate that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged until at least one Ingress collaborator signs off with an LGTM.
Ingress Nginx collaborators may add "/lgtm" (Looks Good To Me) to indicate that a PR is acceptable. Any change requires at least one LGTM. No pull requests can be merged until at least one Ingress Nginx collaborator signs off with an LGTM. Adding the "/lgtm" comment result in the prow bot adding the `lgtm` label. Note that a pull request still needs an `approve` label from one of the owners.
Reviewers or members who want to become reviewers according to the [k8s membership ladder](https://github.com/kubernetes/community/blob/master/community-membership.md), coud actively search for [pull requests that need a review](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+is%3Apr+label%3Atriage%2Faccepted).
## Support Channels

33
ISSUE_TRIAGE.md
View file

@ -10,14 +10,13 @@ The triage process of the ingress-nginx maintainers is based on the [triage proc
However the exact process of the ingress-nginx maintainers may differ in certain aspects. This doc gives a more precise overview on how the ingress-nginx maintainers approach the issue triage process and other processes that are related.
## Triage Flow
## Triage Flow (Issues)
This section describes the different stages of the triage flow.
This section describes the different stages of the triage flow for issues.
### Prepare Issues
New issues come in with the labels `needs-triage` and `needs-priority` and one of: `kind/bug`, `kind/feature` or `kind/support`. Unfortunately there are also some legacy issues that only have a `kind/*` label but neither `needs-triage` nor `needs-priority` . However for every issue that does not have the `triage-accepted` label the following steps have to be done to prepare them for further processing:
* Filter for issues [without the `triage-accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+-label%3Atriage%2Faccepted+is%3Aissue) label.
* Check if all neccessary information are available. This is basically true, if people filled out the issue template correctly. If neccessary information is missing, ask the author to add the missing information and add the label `triage/needs-information` if not already present. If already present, send the author a friendly reminder to add those.
* Check if the used versions of ingress-nginx and Kubernetes is supported. Note that [we only support n-3 versions](https://github.com/kubernetes/ingress-nginx#support-versions-table). If the version is not supported, ask the author to upgrade to newer versions and see if the error still persists.
@ -39,11 +38,35 @@ Who and When?
* Basically every contributor should be able to do that.
* Tricky/important ones could be brought up during community meetings
## Triage Flow (Pull Requests)
This section describes the different stages of the triage flow for pull requests.
### Prepare Pull Requests
Pull requests come in with the labels `needs-triage`, `needs-priority` and `needs-kind` and one that indicates the size(`size/*`). Unfortunately there are also some legacy pull requests that only have a `size/*` label but neither `needs-triage` nor `needs-priority` . However for every pull request that does not have the `triage-accepted` label the following steps should be done to prepare them for further processing:
* Filter for pull requests [without the `triage-accepted`](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+-label%3Atriage%2Faccepted+is%3Apr) label.
* Check if the cla is signed and all neccessary information are available. This is basically true, if people filled out the pull request template correctly. If everything is fine add the `triage-accepted` label.
* If at any point you don't know how to proceed with an issue during the triage process, tag one of the [core maintainers](OWNERS_ALIASES) in the issue to raise attention or alternatively come to [this slack channel](https://kubernetes.slack.com/archives/C021E147ZA4) which may be the quicker way as people tend to miss github notifications.
Who and When?
* Basically everyone who wants to contribute can do the mentioned steps at any time.
### Pull Request Priorization
For all pull requests, where all neccessary information is available and cla is signed thus triage is accepted, we need to do some priorization:
* Go through all pull requests with label [`triage-accepted`](https://github.com/kubernetes/ingress-nginx/pulls?q=is%3Aopen+is%3Apr+label%3Atriage%2Faccepted).
* Sync the `kind/*` and `priority/*` label from the linked issue for the pull request. If the pull request does not have any issue associated (which normally should not be the case), add an appropriate priority and kind label (one of: `priority/backlog`, `priority/critical-urgent`, `priority/important-longterm`, `priority/important-soon`)
Who and When?
* Basically every contributor should be able to do that.
* Tricky/important ones could be brought up during community meetings
## Labels
Labels are helpful for issues to indicate in which lifecycle state they are currently and to categorize them. This section describes the most important ones with the additional info about how to add those. A complete label list of the Kubernetes community can be found [here](https://github.com/kubernetes/kubernetes/labels) while a complete label list for this project can be found [here](https://github.com/kubernetes/ingress-nginx/labels). However, here the most important ones:
Labels are helpful for issues or pull requests to indicate in which lifecycle state they are currently and to categorize them. This section describes the most important ones with the additional info about how to add those. A complete label list of the Kubernetes community can be found [here](https://github.com/kubernetes/kubernetes/labels) while a complete label list for this project can be found [here](https://github.com/kubernetes/ingress-nginx/labels). However, here the most important ones:
* Triage:
* [`needs-triage`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-triage): Indicates that the issue needs triage. Automatically added.
* [`needs-triage`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+is%3Aissue+label%3Aneeds-triage): Indicates that the issue or pull request needs triage. Automatically added.
* [`triage/accepted`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Atriage%2Faccepted+is%3Aissue+): Indicates that the issue is ready for further processing. Add with `/triage accepted`.
* [`triage/needs-information`](https://github.com/kubernetes/ingress-nginx/issues?q=is%3Aopen+label%3Atriage%2Fneeds-information+is%3Aissue+): Indicates that the issue lacks information. Add with `/triage needs-information`.
* Kind: