Update release-notes KEP to reflect the current state

[saschagrunert]

This update for the release notes KEP should layout the current state of
the implementation.

Refers to #1733

/cc @puerco @justaugustus @jeefy

[puerco]

@saschagrunert thanks for the PR. I think your changes capture most of the current direction I understand the project to be taking. There are three different areas we could address when thinking about the KEP:

1. Updating general design issues to where they are now and where they are heading. I think you already mentioned most of them.
2. Addressing those areas where the original ideas from @jeefy 's KEP have already been implemented.
3. Future plans and direction

Here's what I think about those three items:

1. As I said before, I think your changes reflect the current design well, those areas that have shifted from a year ago when the KEP was written.
2. Regarding the actual implementation, I like your checklist because it shows what has been implemented without altering the KEP much.
   If we are trying to reflecting the current progress of the implementation in the KEP itself, there are other areas we ought to note as well. For example, the fact that the website is already up, with it's own domain and out of the personal repo.
3. Finally, there are the plans that lie ahead of us (as of 2020). I think we are due for a good talk on the focus of the tools and how they are used. Mostly derived from the current status of the code but also from the human/organizational side of things.

But perhaps this last point should left out of the KEP. After all, the original intent of the KEP was this:

this KEP would graduate once we have a dedicated release notes website that is automatically updated with minimal human interaction.

And we are at the brink of that. In fact, if we were to leave out the scope of the KEP the bucket issue we could say that the original mission of the KEP has already been fulfilled already as it only takes one command to go from nothing to the PR that updates the website.

What do you think ?

[saschagrunert]

3. Future plans and direction

I'm wondering if this should be part of a new KEP.

And we are at the brink of that. In fact, if we were to leave out the scope of the KEP the bucket issue we could say that the original mission of the KEP has already been fulfilled already as it only takes one command to go from nothing to the PR that updates the website.

What do you think ?

Sounds good! If @justaugustus and @jeefy agrees to, then we could mark this KEP as finished and create a new one on top of that. Was that your intention?

[justaugustus]

/assign @justaugustus
Will review this week.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[saschagrunert]

/remove-lifecycle stale

[justaugustus]

@saschagrunert -- can you look over this and let me know if it's still up-to-date?

[saschagrunert]

@saschagrunert -- can you look over this and let me know if it's still up-to-date?

Should be still fine from my viewpoint. The enhancements @puerco was planning were explicitly kept out of this KEP.

[justaugustus]

Just a few updates before we merge.

[justaugustus]

Thanks!
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/sig-release/OWNERS [justaugustus,saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment