Add enhancement proposal process

enhancements/README.md

@@ -0,0 +1,30 @@
+# Enhancements Tracking and Backlog
+
+Inspired by the [Kubernetes enhancement](https://github.com/kubernetes/enhancements) process.
+
+This folder holds enhancements for scylla-operator. Enhancements are a way of discussing, debating and reaching consensus on how a change should be delivered as well as documenting it. 
+
+Enhancements may be filed from anyone in the community, but require consensus from the maintainers, and a person willing to commit cycles to the implementation.
+
+## Is My Thing an Enhancement?
+
+A rough heuristic for an enhancement is anything that:
+
+- impacts how a scylla is operated including addition or removal of significant
+  capabilities
+- impacts upgrade/downgrade
+- needs significant effort to complete
+- requires broader consensus
+- proposes adding a new user-facing component
+- demands formal documentation to utilize
+
+It is unlikely to require an enhancement if it:
+
+- fixes a bug
+- adds more testing
+- internally refactors a code or component only visible to that components
+  domain
+- minimal impact to distribution as a whole
+
+If you are not sure if the proposed work requires an enhancement, file an issue
+and ask!

enhancements/proposal-template.md

@@ -0,0 +1,107 @@
+# My Enhancement
+
+This is the title of your proposal. Keep it short, simple, and descriptive. A good
+title can help communicate what the proposal is and should be considered as part of
+any review.
+
+## Summary
+
+The `Summary` section is incredibly important for producing high quality
+user-focused documentation such as release notes or a development roadmap.
+
+A good summary is probably at least a paragraph in length.
+
+## Motivation
+
+This section is for explicitly listing the motivation, goals and non-goals of
+this proposal. Describe why the change is important and the benefits to users.
+
+### Goals
+
+List the specific goals of the proposal. How will we know that this has succeeded?
+
+### Non-Goals
+
+What is out of scope for this proposal? Listing non-goals helps to focus discussion
+and make progress.
+
+## Proposal
+
+This is where we get down to the specifics of what the enhancement actually is.
+This should have enough detail that reviewers can understand exactly what
+you're proposing, but should not include things like API designs or
+implementation. What is the desired outcome and how do we measure success?.
+The "Design Details" section below is for the real nitty-gritty.
+
+### User Stories
+
+Detail the things that people will be able to do if this is implemented.
+Include as much detail as possible so that people can understand the "how" of
+the system. The goal here is to make this feel real for users without getting
+bogged down.
+
+#### Story 1
+
+#### Story 2
+
+### Notes/Constraints/Caveats [Optional]
+
+What are the caveats to the proposal?
+What are some important details that didn't come across above?
+Go in to as much detail as necessary here.
+This might be a good place to talk about core concepts and how they relate.
+
+### Risks and Mitigations
+
+What are the risks of this proposal, and how do we mitigate? Think broadly.
+For example, consider both security and how this will impact the ecosystem.
+
+## Design Details
+
+This section should contain enough information that the specifics of your
+change are understandable. This may include API specs (though not always
+required) or even code snippets. If there's any ambiguity about HOW your
+proposal will be implemented, this is the place to discuss them.
+
+### Test Plan
+
+Consider the following in developing a test plan for this enhancement:
+- Will there be e2e tests, in addition to unit tests?
+
+No need to outline all of the test cases, just the general strategy. Anything
+that would count as tricky in the implementation, and anything particularly
+challenging to test, should be called out.
+
+All code is expected to have adequate tests.
+
+### Upgrade / Downgrade Strategy
+
+If applicable, how will the component be upgraded and downgraded? Make sure
+this is in the test plan.
+
+### Version Skew Strategy
+
+How will the component handle version skew with other components?
+What are the guarantees? Make sure this is in the test plan.
+
+## Implementation History
+
+Major milestones in the life cycle of a proposal should be tracked in `Implementation
+History`.
+
+## Drawbacks
+
+Why should this enhancement __not__ be implemented?
+
+## Alternatives
+
+What other approaches did you consider, and why did you rule them out? These do
+not need to be as detailed as the proposal, but should include enough
+information to express the idea and why it was not acceptable.
+
+## Infrastructure Needed [optional]
+
+Use this section if you need things from the project. Examples include a new repo requested, and/or testing infrastructure.
+
+Listing these here allows the community to get the process for these resources
+started right away.