Added proposing features.

FEATURES.md

@@ -0,0 +1,16 @@
+# Proposing Features
+
+A feature request or proposal is an issue opened on a repo in opensearch-project that states an end-user problem, and proposes a solution in the form of a feature. It should meet the following criteria.
+
+- Contains a real use-case or describes a problem.
+- Is a good fit with existing features and the overall direction of the repo and project.
+- Is distinct from existing features.
+- Is atomic.
+
+The primary goal of a feature request is to brainstorm the solutions with the community early. The feature proposal should be opened in the idea stage, or as soon as a problem has been encountered. A technical or an implementation design is not required, but it's recommended to include ideas of possible approaches if you have any. Feature requests are usually labelled as `enhancement` or `feature`, depending on the repo, and often use the [recommended template](.github/ISSUE_TEMPLATE/FEATURE_REQUEST_TEMPLATE.md).
+
+Repo maintainers regularly [triage](TRIAGING.md) new feature requests to determine whether they are valid. There should be no expectation that anyone will pickup the feature request and work on it, including the person who opened it.
+
+Most features can be elevated to the project [roadmap](https://github.com/orgs/opensearch-project/projects/1) by tagging them with a "roadmap" label and a target version number. See [maintaining the project roadmap](RESPONSIBILITIES.md#manage-roadmap) for more information.
+
+Finally, features should be given time before appreciable work begins, allowing for community to voice opinions.

README.md

@@ -19,6 +19,7 @@
 * Need help? Try [Forums](https://forum.opensearch.org/)
 * [Project Principles](https://opensearch.org/about.html#principles-for-development)
 * [Contributing to OpenSearch](CONTRIBUTING.md)
+* [Proposing Features](FEATURES.md)
 * [Onboarding Guide](ONBOARDING.md)
 * [Maintainer Responsibilities](RESPONSIBILITIES.md)
 * [Release Management](RELEASING.md)