Apply suggestions from code review

Co-authored-by: Luca Comellini <[email protected]>
Co-authored-by: Alan Dooley <[email protected]>
Co-authored-by: Shaun <[email protected]>
Signed-off-by: Tomás Ó hAodha <[email protected]>

Author: 4 people

CONTRIBUTING.md

@@ -18,11 +18,11 @@ The following is a set of guidelines for contributing to the NGINX Ingress Contr
 
 ## Ask a Question
 
-To ask the core development team a question please use the [Github Discussions](https://github.com/nginxinc/kubernetes-ingress/discussions) feature.
+To ask a question please use the [Github Discussions](https://github.com/nginxinc/kubernetes-ingress/discussions) feature.
 
 You can also join our [Community Slack channel](https://community.nginx.org/joinslack) which has a wider NGINX audience.
 
-Please reserve Github issues for specific feature requests and bugs rather than general questions.
+Please reserve Github issues for feature requests and bugs rather than general questions.
 
 
 ## Getting Started
@@ -53,11 +53,11 @@ To suggest an new feature or other improvement, create an issue on Github and ch
 
 ### Open a Pull Request
 
-* Before working on a possible pull request, you should first open an associated issue (feature request or bug report) describing the proposed change. This gives an opportunity for the core development team to discuss the potential pull request with you before you do the work.
+* Before working on a possible pull request, first open an associated issue describing the proposed change. This allows the core development team to discuss the potential pull request with you before you do the work.
 * Fork the repo, create a branch, submit a PR when your changes are tested and ready for review
 * Fill in [our pull request template](https://github.com/nginxinc/kubernetes-ingress/blob/main/.github/PULL_REQUEST_TEMPLATE.md)
 
-**Note**: Don't forget to create a feature request / bug report issue first to start a discussion about the proposed change.
+**Note**: Remember to create a feature request / bug report issue first to start a discussion about the proposed change.
 
 ## Style Guides
 

ISSUE_LIFECYCLE.md

@@ -1,8 +1,8 @@
 # Issue Lifecycle
 
-In an effort to ensure a balance between work carried out internally by the NGINX engineering team, while simultaneously encouraging community involvement on this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue lifecycle.)
+To ensure a balance between work carried out by the NGINX engineering team while encouraging community involvement on this project, we use the following issue lifecycle. (Note: The issue *creator* refers to the community member that created the issue. The issue *owner* refers to the NGINX team member that is responsible for managing the issue lifecycle.)
 
-1. New issue created by community member
+1. New issue created by community member.
 
 
 2. Assign issue owner: All new issues are assigned an owner on the NGINX engineering team. This owner shepherds the issue through the subsequent stages in the issue lifecycle.
@@ -21,9 +21,9 @@ In an effort to ensure a balance between work carried out internally by the NGIN
 
 4. Determine milestone: The owner, in collaboration with the wider team (PM & engineering), determines what milestone to attach to an issue. Generally, milestones correspond to product releases - however there are two 'magic' milestones with special meanings (not tied to a specific release):
 
-   - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` item is scheduled for a concrete iteration depends on how well the issue aligns with our roadmap. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out-of-scope`, or relabelled as `backlog-candidate` once it becomes clear that they do not align with our evolving roadmap.
+   - Issues assigned to backlog: Our team is in favour of implementing the feature request/fixing the issue, however the implementation is not yet assigned to a concrete release. If and when a `backlog` issue aligns well with our roadmap, it will be scheduled for a concrete iteration. We review and update our roadmap at least once every quarter. The `backlog` list helps us shape our roadmap, but it is not the only source of input. Therefore, some `backlog` items may eventually be closed as `out-of-scope`, or relabelled as `backlog-candidate` once it becomes clear that they do not align with our evolving roadmap.
 
-   - Issues assigned to backlog-candidate: Our team does not intend to implement the feature request/fix the issue but wants the community to weigh in before we make our final decision.
+   - Issues assigned to `backlog-candidate`: Our team does not intend to implement the feature/fix request described in the issue and wants the community to weigh in before we make our final decision.
 
     `backlog` issues can be labeled by the owner as `help-wanted` and/or `good-first-issue` as appropriate.