Skip to content

Commit

Permalink
Add guidelines for code contributions (#3976)
Browse files Browse the repository at this point in the history
A set of guidelines to decide whether a feature should be included in OpenSearch.

Signed-off-by: Rabi Panda <[email protected]>
  • Loading branch information
adnapibar authored Jul 23, 2022
1 parent 1c787e8 commit efde8c5
Showing 1 changed file with 10 additions and 0 deletions.
10 changes: 10 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,16 @@ If you would like to contribute to the documentation, please do so in the [docum

As with other types of contributions, the first step is to [**open an issue on GitHub**](https://github.com/opensearch-project/OpenSearch/issues/new/choose). Opening an issue before you make changes makes sure that someone else isn't already working on that particular problem. It also lets us all work together to find the right approach before you spend a bunch of time on a PR. So again, when in doubt, open an issue.

Additionally, here are a few guidelines to help you decide whether a particular feature should be included in OpenSearch.

**Is your feature important to most users of OpenSearch?**

If you believe that a feature is going to fulfill a need for most users of OpenSearch, then it belongs in OpenSearch. However, we don't want every feature built into the core server. If the feature requires additional permissions or brings in extra dependencies it should instead be included as a module in core.

**Is your feature a common dependency across multiple plugins?**

Does this feature contain functionality that cuts across multiple plugins? If so, this most likely belongs in OpenSearch as a core module or plugin.

Once you've opened an issue, check out our [Developer Guide](./DEVELOPER_GUIDE.md) for instructions on how to get started.

## Developer Certificate of Origin
Expand Down

0 comments on commit efde8c5

Please sign in to comment.