Add guidelines for code contributions #3976
Conversation
A set of guidelines to decide whether a feature should be included in OpenSearch. Signed-off-by: Rabi Panda <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Co-authored-by: Marc Handalian <[email protected]> Signed-off-by: Rabi Panda <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
|
|
||
| If you believe that your feature is going to fulfill a need for most users of OpenSearch, then this belongs in OpenSearch. However, we don't want every feature to be built into the server, so if the feature requires additional permissions or brings in extra dependencies it should instead be included as a core module. | ||
|
|
||
| **Is your feature a common dependency across multiple plugins?** |
There was a problem hiding this comment.
I like this a lot. I think this also is a good criteria for being an extension point too.
Signed-off-by: Rabi Panda <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Codecov Report
@@ Coverage Diff @@
## main #3976 +/- ##
============================================
+ Coverage 70.56% 70.62% +0.06%
- Complexity 56780 56797 +17
============================================
Files 4573 4573
Lines 273323 273323
Branches 40086 40086
============================================
+ Hits 192859 193028 +169
+ Misses 64239 64019 -220
- Partials 16225 16276 +51
Help us with your feedback. Take ten seconds to tell us how you rate us. |
There was a problem hiding this comment.
I like it. I would also say something about whether the feature can have alternate implementations. For example, for job-scheduler we ask whether job-scheduler be included in core -> will we ever want two different implementations of job-scheduler. If the answer were a definite yes, we'd not want it in core.
I don't use this criteria. Snapshot repository modules, for example, have multiple implementations in core (S3, Azure, GCS). They're in the core as modules because we want them installed as part of the min default experience. I could see two different job schedulers running in parallel using different implementations (cron vs task). |
|
Does this change encourages that as the feature owner we should create plugins or move to a module within the OpenSearch repo? This is bit unclear here. what is the thought process for the same? |
|
We want things to get built in the place makes the most sense for them to be built :) From my POV, it's less about encouraging features owners to build in one place or the other, and more about making sure they're thinking about what is the best place to build things using a lens of commonality. Does that makes sense @navneet1v ? |
Yes it make sense. Thanks for providing the clarity. |
Signed-off-by: Rabi Panda [email protected]
Description
A set of guidelines for contributors to help them deciding whether a feature should be included in OpenSearch.
Issues Resolved
N/A
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.