Initial spike on a tool to help maintainers with KEPs #29
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justinsb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
cncf-cla: yes
justinsb
force-pushed
the
add_kep_explorer
branch
2 times, most recently
from
4d4acc5 to
a258819
Compare
We create a simple website for navigating KEPs. This is really just a first step, to give us somewhere to put advanced features later.
justinsb
force-pushed
the
add_kep_explorer
branch
from
a258819 to
8314507
Compare
|
/assign @ameukam A KEP explorer tool for maintainers! |
|
A Dark Lord at full power. @justinsb IMHO, we should talk to SIG Arch to get a blessing about have the code in a dedicated repo. |
|
I foresee features requests like:
|
| package model | ||
|
|
||
| // KEP represents a Kubernetes Enhancement Proposal | ||
| type KEP struct { |
There was a problem hiding this comment.
Add Created to expose creation-date from the KEP spec ?
There was a problem hiding this comment.
Good call. Right now the order is random (golang maps). I also want to get "in progress" KEPs into the same view, so we have an updated-at timestamp. I would like to claim that I didn't add the date because I figure it will change when we add support for PRs, but that would be a lie :-)
|
/hold Per kubernetes/community#8297 (comment) cc: @kubernetes-sigs/sig-contributor-experience-leads, |
k8s-ci-robot
added
the
do-not-merge/hold
There was a problem hiding this comment.
Can you please mention why this is portrayed as a new thing when there already exists the same thing owned by SIG Architecture, SIG ContribEx and Enhancements Subproject?
The KEP types you add are already present in https://github.com/kubernetes/enhancements/tree/master/api.
The KEP website was implemented roughly about 2 years ago in https://github.com/kubernetes/contributor-site/blob/master/content/en/resources/keps/_index.md.
There is prior art for what is being proposed in this PR. My suggestion would be implement your value-add ideas in addition to the existing implementation.
/cc @dims @johnbelamaric
/cc @kubernetes-sigs/sig-contributor-experience-leads
|
@palnabarun: GitHub didn't allow me to request PR reviews from the following users: kubernetes-sigs/sig-contributor-experience-leads. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Also, please add to the next sig-arch meeting's agenda on the future features that you want to add to the KEP website and/or the KEP metadata. |
+100 I think it makes sense to focus improvements on the already existing KEP website. |
|
@palnabarun this is only the beginning of the feature-set. From the readme: "It doesn't do much yet, it is mostly setting up a framework for us to start to put value-add ideas." We just need a UX so we can start to implement the things that will help maintainers. |
Why not implement them at the relevant places? We don't need or want to duplicate implementations of a KEP website. |
@palnabarun see #30. The two websites may have started superficially similar, but the maintainer tool is going to rapidly become very different from the docs website (aimed at the general kubernetes audience, I assume). If the docs website is willing to host a go webserver, by all means we can put this effort into that project (and I think that suggests a working group or SIG). But I don't think we can build half the things we want to build using only a static webserver. |
|
All due respect, but the kep website isn't really aimed at maintainers who are reviewing proposals. I honestly forgot it existed, because it doesn't do anything I need in those crucial 3 to 4 weeks every 4 months. |
|
My approach is very similar to what Tim expressed in previous comment, whenever reviewing KEPs (either as a SIG lead or as prod-readiness approver) I'll be jumping between the current version of the KEP that I have locally (to see the whole document) and the PR modifying to promote to next stage. Not sure what kind of behavior you're planning to add there, but quickly navigating through documents is available both in github and locally, so is search capability. Several filtering options already exists in the aforementioned KEP site as well. Maybe it would help if you could clarify your planned features first, and see which of those are achievable in that static website and which are not. Based on the latter list enhancement subproject and sig-arch, at minimum, (maybe even pull in chairs and TLs) can decide if those features are desirable by the dev community and do we actually need to expand on that front. |
|
As nice citizens of the community, we should totally file issues whenever we feel there's something we need from an existing area. Last I checked, that's how we did things. Also, any KEP website is as good as the KEP data itself, the custodian of which are the KEP authors and SIG chairs. Edit: adding on. For most parts, even I need to browse the k/enhancements repo locally to find more information on a feature and it has been a constant challenge to dig deeper whenever archaic knowledge has been on people's minds rather than on KEPs. It is a tough problem to solve for. +1 to having a doc/1-pager on the gaps and planned features and proceed accordingly. In all likelihood, KEP related stuff should be with sig-arch and under their purview. |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
We create a simple website for navigating KEPs.
This is really just a first step, to give us somewhere
to put advanced features later.