review feedback

Signed-off-by: Samuel Herman <[email protected]>

FEATURES.md

@@ -3,7 +3,6 @@
   - [Creating meta-issue(s)](#creating-meta-issues)
   - [Writing the code](#writing-the-code)
   - [High level flow](#high-level-flow)
-- [Appendix](#appendix)
 
 # Feature Proposals
 
@@ -14,7 +13,7 @@ A feature proposal is an issue filed on a repo in OpenSearch which outlines the
 - doesn’t overlap or conflict with ongoing work,
 - is sufficiently atomic as a feature.
 
-The feature proposal should be filed in the idea stage, before appreciable work begins and should be the initial review, allowing for community to voice opinions. This provides maximum transparency and involvement across organizational boundaries.
+The feature proposal should be filed in the idea stage according to [this template](https://github.com/opensearch-project/.github/blob/main/.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md). Before appreciable work begins and should be the initial review, allowing for community to voice opinions. This provides maximum transparency and involvement across organizational boundaries.
 
 The process starts with an issue on the repo that you think fits the feature best. In short, the feature proposal issue should describe the end-state of the feature. Each repo now has a template for feature proposals that ask a number of questions relevant to establishing if pursuing the feature is in the best interest of the project. Make sure you fill out the proposal issue template completely, as all questions are required.
 
@@ -51,18 +50,13 @@ The goal for this process is to have a single point of entry for all comers want
 ## High level flow
 | Step | Action | Who | Details |
 |------|--------|-----|---------|
-|1     | New proposal issue | Contributor / Feature proposal owner | Add label: [feature-proposal] |
+|1     | New proposal issue | Contributor / Feature Proposal Owner | Add label: [Enhancement] |
 |2     | Conversation on issue |Maintainer, Contributor, Community| ✅ Feature? ✅ Scope? ✅ Distinct? ✅ Conflict? ✅ Atomic? |
-|3     | Approval of feature proposal | Maintainer |
-|4     | Create new meta-issue(s) and link the sub-tasks involved in delivering this feature | Maintainer, Contributor, Feature proposal owner | ✅ The proposal issue and design PR are linked to the parent META / child meta-issue., ✅ Child meta-issue that tracks all corresponding to targeted OpenSearch release version is created, ✅ The child meta-issue and the corresponding tasks are labelled with targeted OpenSearch version |
-|5     | Add meta-issue(s) card specific to a release version to public roadmap | Maintainer | ✅ Add child meta-issue card to estimated release version |
-|6    | Pull request of feature code | Maintainer, Contributor, Feature proposal owner | ✅ Update the GitHub issues associated with a meta-issue on regular basis ✅ Move the issues to respective release as needed when working through the issues |
-|7    | Code review of feature code | Maintainer, Contributor, Feature proposal owner, Community
-|8    | Approval of code, Maintainer | ✅ Work with the maintainer to get the approval to merge the code |
-|9    | Merging of feature code | Maintainer | ✅ Maintainer will merge the code and add appropriate backport labels |
-|10    | Repeat step 5 to 8 |  Maintainer, Contributor, Feature proposal owner, Community | ✅ Repeat the steps until all meta-issues / Child meta-issues are closed |
-|11    | Close the proposal issue | Maintainer | ✅ Close the proposal once all the meta-issues are closed |
-
-# Appendix
-
-- [Meta-issue format](https://github.com/opensearch-project/.github/blob/main/.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md)
+|3     | Create new meta-issue(s) and link the sub-tasks involved in delivering this feature | Maintainer, Contributor, Feature proposal owner | ✅ The proposal issue and design PR are linked to the parent meta / child meta-issue., ✅ Child meta-issue that tracks all corresponding to targeted OpenSearch release version is created, ✅ The child meta-issue and the corresponding tasks are labelled with targeted OpenSearch version |
+|4     | Add meta-issue(s) card specific to a release version to public roadmap | Maintainer | ✅ Add child meta-issue card to estimated release version |
+|5    | Pull request of feature code | Maintainer, Contributor, Feature proposal owner | ✅ Update the GitHub issues associated with a meta-issue on regular basis ✅ Move the issues to respective release as needed when working through the issues |
+|6    | Code review of feature code | Maintainer, Contributor, Feature proposal owner, Community
+|7    | Approval of code, Maintainer | ✅ Work with the maintainer to get the approval to merge the code |
+|8    | Merging of feature code | Maintainer | ✅ Maintainer will merge the code and add appropriate backport labels |
+|9    | Repeat step 4 to 7 |  Maintainer, Contributor, Feature proposal owner, Community | ✅ Repeat the steps until all meta-issues / Child meta-issues are closed |
+|10    | Close the proposal issue | Maintainer | ✅ Close the proposal once all the meta-issues are closed |

README.md

@@ -21,7 +21,7 @@
 * [Contributing to OpenSearch](CONTRIBUTING.md)
 * [Onboarding Guide](ONBOARDING.md)
 * [Maintainer Responsibilities](RESPONSIBILITIES.md)
-* [Feature Proposal Process](FEATURES.md)
+* [Feature Proposals](FEATURES.md)
 * [Release Management](RELEASING.md)
 * [Organization Admins](ADMINS.md)
 * [Repo Maintainers](MAINTAINERS.md)