-
Notifications
You must be signed in to change notification settings - Fork 70
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: dblock <dblock@amazon.com>
- Loading branch information
Showing
2 changed files
with
18 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
# 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. | ||
|
||
- Is a feature. | ||
- Fits in the scope of the repo and project. | ||
- Is sufficiently distinct from existing features. | ||
- Doesn’t overlap or conflict with ongoing work. | ||
- Is sufficiently 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters