|
| 1 | +# Network Policy Enhancement Proposal (NPEP) |
| 2 | + |
| 3 | +Network Policy Enhancement Proposals (NPEP) serve a similar purpose to the [KEP][kep] |
| 4 | +process for the main Kubernetes project: |
| 5 | + |
| 6 | +1. Ensure that changes to the API follow a known process and discussion |
| 7 | + in the OSS community. |
| 8 | +2. Make changes and proposals discoverable (current and future). |
| 9 | +3. Document design ideas, tradeoffs, decisions that were made for |
| 10 | + historical reference. |
| 11 | + |
| 12 | +## Process |
| 13 | + |
| 14 | +### 1. Discuss with the community |
| 15 | +Before creating a NPEP, share your high level idea with the community. Check |
| 16 | +[Community, discussion, contribution, and support](/#community-discussion-contribution-and-support) |
| 17 | +for the suitable communication option. |
| 18 | + |
| 19 | +### 2. Create an Issue |
| 20 | +[Create a NPEP issue](https://github.com/kubernetes-sigs/network-policy-api/issues/new?assignees=&labels=kind%2Fenhancement&projects=&template=enhancement-proposal.md&title=%5BENHANCEMENT%5D) |
| 21 | +in the repo describing your change. |
| 22 | +At this point, you should copy the outcome of any other conversations or documents |
| 23 | +into this Issue. |
| 24 | + |
| 25 | +### 3. Create a first PR for your NPEP |
| 26 | +NPEP process is supposed to be iterative, adding more details with every iteration. |
| 27 | +Every NPEP has a `Status` field, that is updated with the progress of NPEP. |
| 28 | +Current statuses are: |
| 29 | + |
| 30 | +* "Provisional" |
| 31 | +* "Implementable" |
| 32 | +* "Standard" |
| 33 | + |
| 34 | +they are described in more details further in this section. |
| 35 | +To start NPEP process, create a PR adding `npep-<issue number>.md` file in the |
| 36 | +[npep folder](https://github.com/kubernetes-sigs/network-policy-api/tree/master/npep) |
| 37 | +using the [template NPEP](https://github.com/kubernetes-sigs/network-policy-api/blob/master/npep/npep-95.md) as a starting point. |
| 38 | + |
| 39 | +### 4. Provisional: Agree on the Goals |
| 40 | +Although it can be tempting to start writing out all the details of your |
| 41 | +proposal, it's important to first ensure we all agree on the goals. The first |
| 42 | +version of your NPEP should have "Provisional" status and leave out any implementation details, |
| 43 | +focusing primarily on "Goals" and "Non-Goals". |
| 44 | + |
| 45 | +### 5. Implementable: Document Implementation Details |
| 46 | +Now that everyone agrees on the goals, it is time to start writing out your |
| 47 | +proposed implementation details. These implementation details should be very |
| 48 | +thorough, including the proposed API spec, and covering any relevant edge cases. |
| 49 | +Note that it may be helpful to use a shared doc for part of this phase to enable |
| 50 | +faster iteration on potential designs. |
| 51 | + |
| 52 | +It is likely that throughout this process, you will discuss a variety of |
| 53 | +alternatives. Be sure to document all of these in the NPEP, and why we decided |
| 54 | +against them. At this stage, the NPEP should be targeting the "Implementable" stage. |
| 55 | + |
| 56 | +### 6. Standard: Make API changes |
| 57 | +With the NPEP marked as "Implementable", it is time to actually make the proposed changes in our API. |
| 58 | +In some cases, these changes will be documentation |
| 59 | +only, but in most cases, some API changes will also be required. |
| 60 | + |
| 61 | +When updating NPEP from "Implementable" to "Standard", status update may be the |
| 62 | +only required change, but also feel free to link any API, docs, etc. changes that |
| 63 | +were made as an implementation for a given NPEP. |
| 64 | + |
| 65 | +Before changes are released they MUST be documented. NPEPs that have not been |
| 66 | +both implemented and documented before a release cut off will be excluded from |
| 67 | +the release. |
| 68 | + |
| 69 | + |
| 70 | +### 7. Close out the NPEP issue |
| 71 | +The NPEP issue should only be closed when the work is "done" (whatever |
| 72 | +that means for that NPEP). |
| 73 | + |
| 74 | +## Out of scope |
| 75 | + |
| 76 | +What is out of scope: see [text from KEP][kep-when-to-use]. Examples: |
| 77 | + |
| 78 | +* Bug fixes |
| 79 | +* Small changes (API validation, documentation, fixups). It is always |
| 80 | + possible that the reviewers will determine a "small" change ends up |
| 81 | + requiring a NPEP. |
| 82 | + |
| 83 | +[kep]: https://github.com/kubernetes/enhancements |
| 84 | +[kep-when-to-use]: https://github.com/kubernetes/enhancements/tree/master/keps#do-i-have-to-use-the-kep-process |
0 commit comments