From c824f9203d8a2b244e75bc3d72c3467dd1c424f9 Mon Sep 17 00:00:00 2001
From: David Justice <devigned@users.noreply.github.com>
Date: Wed, 20 Nov 2024 07:25:06 -0500
Subject: [PATCH] create the hyperlight proposal process (#25)

Signed-off-by: David Justice <david@devigned.com>
Co-authored-by: Dan Chiarlone <danilochiarlone@gmail.com>
---
 proposals/0000-hip-process/README.md  |  38 ++++++
 proposals/NNNN-hip-template/README.md | 177 ++++++++++++++++++++++++++
 proposals/README.md                   |  25 ++++
 3 files changed, 240 insertions(+)
 create mode 100644 proposals/0000-hip-process/README.md
 create mode 100644 proposals/NNNN-hip-template/README.md
 create mode 100644 proposals/README.md

diff --git a/proposals/0000-hip-process/README.md b/proposals/0000-hip-process/README.md
new file mode 100644
index 00000000..7bec13fa
--- /dev/null
+++ b/proposals/0000-hip-process/README.md
@@ -0,0 +1,38 @@
+# Hyperlight Improvement Process
+
+<!-- toc -->
+- [Summary](#summary)
+- [Motivation](#motivation)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+- [Proposal](#proposal)
+<!-- /toc -->
+
+## Summary
+
+Hyperlight Improvement Proposals, otherwise known as HIPs, are largely influenced by the Kubernetes
+Enhancement Proposal (KEP) process which provides a standardized development process for Hyperlight
+enhancements. You can read more about the
+[KEP process in 0000-kep-process here](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md).
+
+## Motivation
+
+### Goals
+
+1. Since Hyperlight is a smaller project than Kubernetes and has a smaller community of contributors, the
+needs are slightly different from that of the Kubernetes project. HIPs do not strive to meet the rigor
+of their inspiration in Kubernetes, but rather, to provide a means for communication of intent and a
+historical record for the motivations that drove the improvement.
+
+### Non-goals
+
+1. To have all changes require a HIP. Only significantly impacting work should be stated as a HIP, e.g. 
+a large refactoring, significant feature enhancements, breaking APIs, etc.
+2. We will omit the use of KEP like metadata that is associated with KEPs.
+
+## Proposal
+
+We propose creating a standardized improvement proposal process for Hyperlight modeled after the Kubernetes
+Enhancement Proposal process.
+
+
diff --git a/proposals/NNNN-hip-template/README.md b/proposals/NNNN-hip-template/README.md
new file mode 100644
index 00000000..b6ca1622
--- /dev/null
+++ b/proposals/NNNN-hip-template/README.md
@@ -0,0 +1,177 @@
+# HIP NNNN - SKIP NAME
+
+<!-- toc -->
+- [Summary](#summary)
+- [Motivation](#motivation)
+    - [Goals](#goals)
+    - [Non-Goals](#non-goals)
+- [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)
+    - [Test Plan](#test-plan)
+        - [Unit tests](#unit-tests)
+        - [Integration tests](#integration-tests)
+        - [e2e tests](#e2e-tests)
+- [Implementation History](#implementation-history)
+- [Drawbacks](#drawbacks)
+- [Alternatives](#alternatives)
+<!-- /toc -->
+
+## Summary
+
+<!--
+This section is incredibly important for producing high-quality, user-focused
+documentation such as release notes or a development roadmap. It should be
+possible to collect this information before implementation begins, in order to
+avoid requiring implementors to split their attention between writing release
+notes and implementing the feature itself. HIP editors should help to ensure 
+that the tone and content of the `Summary` section is useful for a wide audience.
+
+A good summary is probably at least a paragraph in length.
+
+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 HIP.  Describe why the change is important and the benefits to users. The
+motivation section can optionally provide links to [experience reports] to
+demonstrate the interest in a KEP within the wider Kubernetes community.
+
+[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
+-->
+
+### Goals
+
+<!--
+List the specific goals of the HIP. What is it trying to achieve? How will we
+know that this has succeeded?
+-->
+
+### Non-Goals
+
+<!--
+What is out of scope for this HIP? Listing non-goals helps to focus discussion
+and make progress.
+-->
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal 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 (Optional)
+
+<!--
+Detail the things that people will be able to do if this HIP 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 larger ecosystem.
+
+How will security be reviewed, and by whom?
+-->
+
+## 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
+
+<!--
+The goal is to ensure that we don't accept enhancements with inadequate testing.
+
+All code is expected to have adequate tests (eventually with coverage
+expectations).
+-->
+
+##### Unit tests
+
+<!--
+In principle every added code should have complete unit test coverage, so providing
+the exact set of tests will not bring additional value.
+However, if complete unit test coverage is not possible, explain the reason of it
+together with explanation why this is acceptable.
+-->
+
+##### Integration tests
+
+<!--
+Integration tests allow control of the configuration parameters used to start the binaries under test.
+This is different from e2e tests which do not allow configuration of parameters.
+Doing this allows testing non-default options and multiple different and potentially conflicting command line options.
+-->
+
+##### e2e tests
+
+<!--
+We expect no non-infra related flakes in the last month as a GA graduation criteria.
+-->
+
+## Implementation History
+
+<!--
+Major milestones in the lifecycle of a HIP should be tracked in this section.
+Major milestones might include:
+- the `Summary` and `Motivation` sections being merged, signaling SIG acceptance
+- the `Proposal` section being merged, signaling agreement on a proposed design
+- the date implementation started
+- the first Hyperlight release where an initial version of the HIP was available
+- the version of Hyperlight where the HIP graduated to general availability
+- when the HIP was retired or superseded
+-->
+
+## Drawbacks
+
+<!--
+Why should this HIP _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.
+-->
diff --git a/proposals/README.md b/proposals/README.md
new file mode 100644
index 00000000..918bd311
--- /dev/null
+++ b/proposals/README.md
@@ -0,0 +1,25 @@
+# Hyperlight Improvement Proposals (HIPs)
+
+Hyperlight Improvement Proposals, otherwise known as HIPs, are largely influenced by the Kubernetes
+Enhancement Proposal (KEP) process which provides a standardized development process for Hyperlight
+enhancements. You can read more about the 
+[KEP process in 0000-kep-process here](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md).
+
+## Authoring a HIP
+When you have a new enhancement that is more than a relatively trivial enhancement or bug fix, the
+change should be first socialized as a HIP. To help authors to get started a HIP template is located in
+[NNNN-hip-template](./NNNN-hip-template/README.md). 
+
+1. Create a new directory under [the proposals directory](../proposals) in the form of `NNNN-hip-${hip_name}`
+  where `NNNN` is the next HIP number available. For example, if HIP 0001 is currently the highest number HIP and
+  your enhancement is titled "Make Me a Sandwich", then your HIP would be `0002-hip-make-me-a-sandwich`.
+2. Within your `NNNN-hip-${hip_name}` directory create a file named `README.md` containing a copy of the HIP
+  template.
+3. Author the content of the template. Not all sections are necessary. Please consider filling out the
+  summary, motivation, and proposal sections first to gather early feedback on the desirability of the
+  enhancement through a draft pull request.
+4. After socializing the proposal and integrating early feedback, continue with the rest of the sections.
+5. Update the pull request with the rest of the sections and remove the draft status from the pull request.
+6. Address any feedback to the proposal and get it merged.
+7. Implement the enhancement.
+