adding cve finding and adding release-notes to PR template

.github/ISSUE_TEMPLATE/cve_report.md

@@ -0,0 +1,20 @@
+---
+name: CVE Finding Report
+about: CVE reporting for ingress-nginx
+title: ''
+labels: kind/bug
+assignees:
+    - strongjz
+    - rikatz
+---
+
+<!-- if you found something that impacts directly ingress-nginx and 
+is not a public CVE yet, please reach out [email protected]" -->
+
+<!-- What scanner and version reported the CVE? -->
+
+<!-- What CVE was reported in the scanner findings? -->
+
+<!-- What versions of the controller did you test with?  -->
+
+<!-- Please provider other details that will help us determine the severity of the issue -->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -15,8 +15,6 @@ The announcement in the dev mailing list is here https://groups.google.com/a/kub
 
 Thank you,
 Ingress-Nginx maintainer
-
-
 -->
 
 <!-- What do you want to happen? -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -9,6 +9,7 @@
 <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
 - [ ] Bug fix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
+- [ ] CVE Report (Scanner found CVE and adding report)
 - [ ] Breaking change (fix or feature that would cause existing functionality to change)
 - [ ] Documentation only
 
@@ -30,5 +31,38 @@ fixes #
 - [ ] My change requires a change to the documentation.
 - [ ] I have updated the documentation accordingly.
 - [ ] I've read the [CONTRIBUTION](https://github.com/kubernetes/ingress-nginx/blob/main/CONTRIBUTING.md) guide
-- [ ] I have added tests to cover my changes.
+- [ ] I have added unit and/or e2e tests to cover my changes.
 - [ ] All new and existing tests passed.
+- [ ] Added Release Notes.
+
+## Does my pull request need a release note?
+Any user-visible or operator-visible change qualifies for a release note. This could be a:
+
+- CLI change
+- API change
+- UI change
+- configuration schema change
+- behavioral change
+- change in non-functional attributes such as efficiency or availability, availability of a new platform
+- a warning about a deprecation
+- fix of a previous Known Issue
+- fix of a vulnerability (CVE)
+
+No release notes are required for changes to the following:
+
+- Tests
+- Build infrastructure
+- Fixes for unreleased bugs
+
+For more tips on writing good release notes, check out the [Release Notes Handbook](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-notes)
+
+<!--
+If no, just write "NONE" in the release-note block below.
+If yes, a release note is required:
+Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required".
+
+For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md
+-->
+```release-note
+PLACE RELEASE NOTES HERE 
+```