-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define and implement entry/exit criteria for kubernetes-maintainers GitHub team #2332
Comments
cc @kubernetes/owners cc @dims @derekwaynecarr @johnbelamaric cc @liggitt @sttts @deads2k @tpepper @justaugustus |
+1. It's been needed for some time. |
+1 to prune. isn't milestone-maintainers a larger group? |
+1 |
Is this suggesting we remove current members of the kubernetes-maintainers list if either of the following are true:
If so, that seems very reasonable to me and moves in the desired direction of shrinking the list. |
Yes 👍 |
To clarify - we won't bulk-add milestone-maintainers + k/k approvers if they aren't already in the If someone in milestone-maintainers + k/k approvers wants to be on the team, they can create a PR to add themselves separately. Want to keep the team as small as possible. |
One note
What would be the approval process here? |
Thinking more about this, how about:
|
I like this.
Hmmmmm, so I think there should be a route to write access. @dims is not a root approver for k/k, but I do feel he's deserving of the access that was granted in #2330. How can we cover those cases in future? |
I think this is accurate at this point 🙃 xref: kubernetes#2332 (comment) kubernetes#2330
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
NOTE: due to branch protection We should prune inactive members. I disagree that we should refuse to add anyone new. Being able to manually correct PR state (PR body, labels) is quite useful, and we should be able to trust people with this (approvers or maybe SIG chairs / leads). EDIT: |
What requirements do triagers have that could not be covered with the
|
I'm fine trying the triage role but would prefer we ensure peribolos has support for that. Unclear to me how actively it's used elsewhere |
https://kubernetes.slack.com/archives/C1L57L91V/p1614017710014100 based on k/enhancements experience with the triage role, I don't think it meets our needs here (inability to edit issue/pr descriptions) |
We need to decide on policy to prune, and policy to add. Then implement. Summarizing what I've read above from @nikhita @liggitt @BenTheElder @justaugustus Possible reasons to prune:
Would like to understand what the reduction would be based on each of these. My preference would be C. If only I knew how to measure it at a glance... Requirements to be added:
My preference would be C |
I don't think
|
/retitle Define and implement entry/exit criteria for kubernetes-maintainers GitHub team |
/help A: parse all OWNERS files in kubernetes/kubernetes
B: diff the two teams' membership
C: this is the one I'm not sure about
D: intersection of the above
|
@spiffxp: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed 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/test-infra repository. |
@kubernetes/release-engineering -- Anyone interested in helping out here? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
I have also recently found it more productive to fix PR bodies that do not meet our template criteria after one attempt at telling the author to please do this than lengthy back and forth (especially with time zone latency this can become very drawn out). Things like the release-note "language" code block trip people up and are trivial for a maintainer with write to fix. We have a lot of things built around expecting PR metadata to be just so and everything is built around having the source of truth be in PRs themselves. Otherwise I'd suggest redesigning the mechanisms. E.g. cherry picks rely on parent PR's note so it would be somewhat prohibitive to move it to say scanning all comments on the PR. In addition to brach protection we also monitor pushes and alert in other repos, we should be doing this here. |
/milestone v1.23 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
TIL https://prow.k8s.io/command-help /release-note-edit (which ... can't be linked to ... that's broken ...) It looks ... awkward to use (multi-line??) but ... one possible option for that aspect ... if we make people aware of it. I'm also not sure if this works in the face of mangling the "language" as mentioned previously, I think it just substitutes the contents of an already correctly formatted block. Still, a somewhat promising thought.
we should still really have this |
The legacy kubernetes-maintainers GitHub team has write access to the k/k repo. This issue is to discuss pruning the team.
There has been previous discussion about removing the team in kubernetes/kubernetes#57667. Given that we don't have good automated solutions around editing issue/PR bodies, completely removing write access and deleting the team is not feasible today.
Having said that, the
kubernetes-maintainers
team hasn't had any significant updates over the last ~3 years (!!!). There are members in that team who are no longer active in the Kubernetes project and should not have write access to k/k anymore.My suggestion - we could limit this to milestone-maintainers + all approvers in k/k.
If there is general consensus on this GitHub issue, I'll start a thread on the k-dev and leads mailing lists.
The text was updated successfully, but these errors were encountered: