Add proposal template and instructions in docs

Signed-off-by: nikimanoledaki <[email protected]>

CONTRIBUTING.md

@@ -37,3 +37,15 @@ Recommendations for a faster Pull Request review:
   - **Signed**: Include a `Signed-off-by: Author Name <[email protected]>` in all commits by doing `git rebase HEAD~2 --signoff` (replace `~2` with the number of commits to sign) and then `git push -f`. More info [here](https://github.com/cncf-tags/green-reviews-tooling/pull/53/checks?check_run_id=21563565653).
   - **Verified**: [Learn more about commit signature verification with GPG.](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#gpg-commit-signature-verification)
 - The Kubernetes Best Practices for faster Reviews is a great resource for PR best practices: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews
+
+### Proposals
+
+For larger feature requests, please submit a design proposal in [docs/proposals/](./docs/proposals/). This is similar to a [Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements) or a [Architecture Desicision Record (ADR)](https://github.com/joelparkerhenderson/architecture-decision-record).
+
+First, create a copy of the template found in the proposal directory, [docs/proposals/proposal-000-template.md](./docs/proposals/proposal-000-template.md). Rename the file to the next number in the sequence and add a name for the proposal e.g. `proposal-001-my-feature.md`. Fill in the required fields, then open a PR for review.
+
+The initial PR can be a barebone PR with the goals/non-goals sections clarified that can be merged quickly and iterated on.
+
+Initial merging of the PR does not mean that the proposal is approved. The status of the PR is defined in the `Status` section. Any KEP marked as `provisional` is a working document and subject to change.
+
+A proposal that is accepted is a living document. Even the most well-planned ideas may change at some point.

docs/proposals/README.md

@@ -0,0 +1,11 @@
+# Proposals
+
+How to use the proposal template:
+
+- Make a copy of this file in this (`docs/proposals/`) directory
+- Set the name of the file to contain the next logical number and the name of the feature
+- Fill out at least the Status, Motivation and Goals/Non-Goals fields.
+- Open a PR to the `green-reviews-tooling` repository
+- Merge early and iterate
+
+For more tips see the Contributing docs: https://github.com/cncf-tags/green-reviews-tooling/blob/main/CONTRIBUTING.md#proposals

docs/proposals/proposal-000-template.md

@@ -0,0 +1,203 @@
+<!--
+How to use this template:
+
+- Make a copy of this file in the docs/proposals/ directory
+- Set the name of the file to contain the next logical number and the name of the feature
+- Fill out at least the Status, Motivation and Goals/Non-Goals fields.
+- Open a PR to green-reviews-tooling
+- Merge early and iterate
+
+For more tips see the Contributing docs: https://github.com/cncf-tags/green-reviews-tooling/blob/main/CONTRIBUTING.md#proposals
+-->
+
+# Short, descriptive title
+
+<!--
+Keep the title short, simple, and descriptive. A good
+title can help communicate what the proposal is and should be
+considered as part of any review.
+-->
+
+## Authors
+
+<!--
+Who is responsible for this proposal? Who can answer questions?
+-->
+
+## Status
+
+<!--
+Must be one of provisional, implementable, implemented, deferred,
+rejected, withdrawn, or replaced.
+-->
+
+
+<!--
+The headings here are just starting points, add more as makes sense in what you
+are proposing.
+-->
+## Table of Contents
+<!-- toc -->
+- [Short, descriptive title](#short-descriptive-title)
+  - [Authors](#authors)
+  - [Status](#status)
+  - [Table of Contents](#table-of-contents)
+  - [Summary](#summary)
+  - [Motivation](#motivation)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+    - [Linked Docs](#linked-docs)
+  - [Proposal](#proposal)
+    - [User Stories (Optional)](#user-stories-optional)
+      - [Story 1](#story-1)
+      - [Story 2](#story-2)
+    - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
+    - [Risks and Mitigations](#risks-and-mitigations)
+  - [Design Details](#design-details)
+    - [Graduation Criteria (Optional)](#graduation-criteria-optional)
+  - [Drawbacks (Optional)](#drawbacks-optional)
+  - [Alternatives](#alternatives)
+  - [Infrastructure Needed (Optional)](#infrastructure-needed-optional)
+<!-- /toc -->
+
+## Summary
+
+<!--
+A good summary is at least a paragraph in length and should be written with a wide audience
+in mind.
+
+It should encompass the entire document, and serve as both future documentation
+and as a quick reference for people coming by to learn the proposal's purpose
+without reading the entire thing.
+
+Both in this section and below, follow the guidelines of the [documentation
+style guide]. In particular, wrap lines to a reasonable length, to make it
+easier for reviewers to cite specific portions, and to minimize diff churn on
+updates.
+
+[documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
+-->
+
+## Motivation
+
+<!--
+This section is for explicitly listing the motivation, goals and non-goals of
+this proposal. Describe why the change is important, how it fits into the project's
+goals and the benefits to users.
+
+It is helpful to frame this to answer the question: "What is the problem this proposal
+is trying to solve?"
+-->
+
+### Goals
+
+<!--
+List the specific goals of the proposal. What is it trying to achieve? 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.
+
+It is important to remember that non-goals are still equally important things
+which will be dealt with one day but are not things which need to be dealt with immediately
+within the scope of this work. This helps make sure everyone is crystal clear on the outcomes.
+-->
+
+### Linked Docs
+
+<!--
+Provide links to previous discussions, Slack threads, motivation issues or any other document
+with context. It is really helpful to provide a "source of truth" for the work
+so that people aren't searching all over the place for lost context.
+-->
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal actually is:
+outlining your solution to the problem described in the Motivation section.
+This should have enough detail that reviewers can understand exactly what
+you're proposing, but should not include things like API designs or
+implementation. The "Design Details" section below is for the real
+nitty-gritty.
+-->
+
+### User Stories (Optional)
+
+<!--
+Detail the things that people will be able to do if this proposal 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 how this will impact or be impacted
+by scaling to support more CNCF Projects.
+
+How will this affect the benchmark tests, CNCF Project Maintainers, pipeline maintainers, etc?
+-->
+
+## Design Details
+
+<!--
+This section should contain enough information that the specifics of your
+change are understandable. This may include manifests or workflow examples
+(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.
+-->
+
+### Graduation Criteria (Optional)
+
+<!--
+List criteria which would allow progression from one maturity level to another.
+eg. What needs to have been accomplished/demonstrated to move from Alpha to Beta.
+
+If applicable, what is the milestone marker which will allow deprecation of the
+replaced capability?
+-->
+
+## Drawbacks (Optional)
+
+<!--
+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.
+-->
+
+## 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 (pros and cons are fine),
+but should include enough information to express the idea and why it was not acceptable
+as well as illustrate why the final solution was selected.
+-->
+
+## Infrastructure Needed (Optional)
+
+<!--
+Use this section if you need things from the project/SIG. Examples include a
+new subproject, repos requested, or GitHub details. Listing these here allows a
+SIG to get the process for these resources started right away.
+-->