refactor: Templates

.github/CODEOWNERS

@@ -1,12 +1,6 @@
 # CODEOWNERS
-# These owners will be the default owners for everything in
+# Global owners: Default owners for everything in
 # the repo. Unless a later match takes precedence,
-# @zhengyi will be requested for
-# review when someone opens a pull request.
-*       @zhengyi
-*       @ARCHU-S-M
-*       @David-Gay
-*       @joseph-stanley
-*       @Rahul-Mourya2
-*       @sujeily-fonseca
-*       @Sujesh-T
+# @global-owner will be requested for review when
+# someone opens a pull request.
+* @sujeily-fonseca @zhengyi

.github/ISSUE_TEMPLATE/bug_report.md

@@ -6,7 +6,7 @@ labels: 'bug'
 assignees: ''
 ---
 
-<!-- If you are trying to resolve an environment-specific issue or have a one-off question about the edge case that does not require a feature then please consider asking a question in argocd slack [channel](https://argoproj.github.io/community/join-slack). -->
+<!-- If you are trying to resolve an environment-specific issue or have a one-off question about the edge case that does not require a feature, then please consider asking a question in Argo CD Slack [channel](https://argoproj.github.io/community/join-slack). -->
 
 Checklist:
 

.github/ISSUE_TEMPLATE/enhancement_proposal.md

@@ -7,11 +7,11 @@ assignees: ''
 ---
 # Summary
 
-What change you think needs making.
+What change do you think needs making?
 
 # Motivation
 
-Please give examples of your use case, e.g. when would you use this.
+Please give examples of your use case, e.g., when would you use this.
 
 # Proposal
 

.github/ISSUE_TEMPLATE/release.md

@@ -1,6 +1,6 @@
 ---
 name: Argo CD Release
-about: Used by our Release Champion to track progress of a minor release
+about: Used by our Release Champion to track the progress of a minor release
 title: 'Argo CD Release vX.X'
 labels: 'release'
 assignees: ''
@@ -10,23 +10,23 @@ Target RC1 date: ___. __, ____
 Target GA date: ___. __, ____
 
  - [ ] Create new section in the [Release Planning doc](https://docs.google.com/document/d/1trJIomcgXcfvLw0aYnERrFWfPjQOfYMDJOCh1S8nMBc/edit?usp=sharing)
- - [ ] Schedule a Release Planning meeting roughly two weeks before the scheduled Release freeze date by adding it to the community calendar (or delegate this task to someone with write access to the community calendar)
+ - [ ] Schedule a Release Planning meeting roughly two weeks before the scheduled Release freeze date by adding it to the community calendar (or delegate this task to someone with written access to the community calendar)
      - [ ] Include Zoom link in the invite
  - [ ] Post in #argo-cd and #argo-contributors one week before the meeting
  - [ ] Post again one hour before the meeting
  - [ ] At the meeting, remove issues/PRs from the project's column for that release which have not been “claimed” by at least one Approver (add it to the next column if Approver requests that)
  - [ ] 1wk before feature freeze post in #argo-contributors that PRs must be merged by DD-MM-YYYY to be included in the release - ask approvers to drop items from milestone they can’t merge
  - [ ] At least two days before RC1 date, draft RC blog post and submit it for review (or delegate this task)
  - [ ] Cut RC1 (or delegate this task to an Approver and coordinate timing)
- - [ ] Create new release branch
+ - [ ] Create a new release branch
     - [ ] Add the release branch to ReadTheDocs
     - [ ] Confirm that tweet and blog post are ready
     - [ ] Trigger the release
     - [ ] After the release is finished, publish tweet and blog post
     - [ ] Post in #argo-cd and #argo-announcements with lots of emojis announcing the release and requesting help testing
  - [ ] Monitor support channels for issues, cherry-picking bugfixes and docs fixes as appropriate (or delegate this task to an Approver and coordinate timing)
- - [ ] At release date, evaluate if any bugs justify delaying the release. If not, cut the release (or delegate this task to an Approver and coordinate timing)
+ - [ ] At the release date, evaluate if any bugs justify delaying the release. If not, cut the release (or delegate this task to an Approver and coordinate timing)
  - [ ] If unreleased changes are on the release branch for {current minor version minus 3}, cut a final patch release for that series (or delegate this task to an Approver and coordinate timing)
  - [ ] After the release, post in #argo-cd that the {current minor version minus 3} has reached EOL (example: https://cloud-native.slack.com/archives/C01TSERG0KZ/p1667336234059729)
- - [ ] (For the next release champion) Review the [items scheduled for the next release](https://github.com/orgs/argoproj/projects/25). If any item does not have an assignee who can commit to finish the feature, move it to the next release.
+ - [ ] (For the next release champion) Review the [items scheduled for the next release](https://github.com/orgs/argoproj/projects/25). If any item does not have an assignee who can commit to finishing the feature, move it to the next release.
  - [ ] (For the next release champion) Schedule a time mid-way through the release cycle to review items again.

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -1,45 +1,29 @@
-Pull Request Template
-
-# Description
-
-Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
-
-## Reviewer(s)
-
-@zhengyi
-@archu.s.m
-@davidgay
-@joseph.stanley
-@Rahul Mourya
-@Sujeily Fonseca-Gonzalez
-@Sujesh T
+# Pull Request Template
 
+## Description
+Please include a summary of the changes and the related issues. Please also include relevant motivation and context. List any dependencies that are required for this change.
 
 ## Linked Issue(s)
-
 Fixes # (issue)
 
 ## Type of change
-
 Please delete options that are not relevant.
 
 - [ ] Bug fix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
 - [ ] This change requires a documentation update
 
-# How Has This Been Tested?
-
-Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
+# How has this been tested?
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.
 
 - [ ] Test A
 - [ ] Test B
 
 # Checklist:
-
 - [ ] My code follows the style guidelines of this project
 - [ ] I have performed a self-review of my code
-- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have commented on my code, particularly in hard-to-understand areas
 - [ ] I have made corresponding changes to the documentation
 - [ ] My changes generate no new warnings
 - [ ] I have added tests that prove my fix is effective or that my feature works