Closed bgrant0607 closed 6 years ago
For me it was primarily for setting release-notes labels, and assigning PRs to reviewers. I got added into the maintainers list but then I learned that I'd have to help fix flaky tests (got assigned 10+ test issues I had no clue what were) so I decided to quit. After all I could ping somebody else from the team to add the labels for me.
Mostly, be able to set:
component/kubeadm
insted of component/kubectl
And last but not least, @kubernetes/sig-cluster-lifecycle is very active these days, and the people that are currently involved + have maintainer permissions are @luxas @mikedanese and @jbeda, alone, all of which very busy folks. There are a couple guys involved full-time in this SIG (in the top 100 contributors) that could/want to help ease their load - yes, I'm one of those. @errordeveloper is the other I'd suggest. This is something we have been debating but since there's no process (yet?) available, I thought of applying. At least it seems to have contributed to this issue 👍
@pires If most of your work is on kubeadm, your problem would be solved by moving kubeadm to its own repo. :-)
lgtm
label once I'm LGTM in reviews (already being assigned as reviewer by others)release-note-*
labelscomponent/kubectl
, area/usability
, kind/bug
, kind/enhancement
, kind/feature
(for issues related to the cli)The request is related to my work with @kubernetes/sig-cli, meaning (but not restricted to) pkg/kubectl
. Other related bits: pkg/util/term
, pkg/util/httpstream
(proxy support in the cli, etc), pkg/client
, pkg/util/wait
, pkg/watch
, bumping vendor dependencies like spf13/cobra
and spf13/pflag
, etc.
Tks! ;)
@fabianofranz LGTM can be achieved by /lgtm
now, FYI, if the PR is assigned to you.
LGTM can be achieved by /lgtm now, FYI, if the PR is assigned to you.
Didn't know that, thanks!
@bgrant0607 as we speak, yes, it is just kubeadm
, in terms of code. But, as part of the aforementioned SIG's interest, we're looking into not just proposing design but also implementing stuff that will be leveraged by kubeadm
and other tools in the future, namely self-hosted (kubelet pod api, checkpointing) and HA (discovery, TLS bootstrap). May I add this is of other SIGs' interest, as well, e. g. sig-node.
Just to make sure you understand my past as a contributor, until very recently, I had nothing to do with kubeadm
or this SIG - such concepts didn't event exist before.
For me, mostly be able to
I used my write access for:
Without write-access, these inconveniences can be alleviated by:
/label kind/bug
similar to /lgtm
)However, since the push to the main repo is disabled, benefit of write access is the ones listed so far which are only related to issues/PRs.
Set lgtm label? Yes Set release-note labels? No, do not have this in kops Set milestone on PR or issue? Yes Self-assign PR or issue? Yes Assign PR to someone else? Yes Assign issue to someone else? Yes Set some other labels on issues (which ones)? Yes, kops specific Set some other labels on PRs (which ones)? Yes, kops specific Edit wiki - no Something else (what)? We also needed help setting up CI webhooks.
I am still not able to edit and add labels on the kops repo, which is kinda a pain.
At first, my request was purely because it was a step on our new hire checklist (which we can remove). I'm still pretty new to the team and Google, so my asks might grow over time, but so far all I've wanted to do is assign issues to myself to mark what I'm working on.
Jacob
On Fri, Oct 21, 2016 at 9:28 AM Daniel Wang notifications@github.com wrote:
For me it was primarily for setting release-notes labels, and assigning PRs to reviewers. I got added into the maintainers list but then I learned that I'd have to help fix flaky tests (got assigned 10+ test issues I had no clue what were) so I decided to quit. After all I could ping somebody else from the team to add the labels for me.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/1908#issuecomment-255421472, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiBXeMfXjsAQGDvaPHhELr1N4MiRL3hks5q2OhIgaJpZM4KdZgN .
Mostly acting as a PM contributor and features maintainer, I'm interested in:
Set release-note labels Set milestone on PR or issue Self-assign PR or issue Assign PR to someone else Assign issue to someone else Set some other labels on issues - assign to SIGs, label with the actual feature status Set some other labels on PRs - assign to SIGs, label with the actual feature status Edit wiki Something else - other PM-related actions
Thanks.
+1000 to issue hygiene.
@bgrant0607 thanks for addressing this! How will the bots work with this?? We need k8s-bot in kops.
@chrislovecnm @k8s-bot's code lives in the test-infra repo under prow. We're going to add more commands there. Feel free to file issues there with requests.
I really just want to be able to help triage tickets (close, reassign, etc) and help triage PRs (close, reassign, etc). Right now I feel helpless and have to rely on extremely busy people to do that.
Set lgtm label? yes Set release-note labels? no Set milestone on PR or issue? yes Self-assign PR or issue? yes Assign PR to someone else? yes Assign issue to someone else? yes Set some other labels on issues (which ones)? kind/area/etc Set some other labels on PRs (which ones)? kind/area/etc
Something else (what)?
@bgrant0607 the other way to do this would be to remove everyone's access outside of https://github.com/kubernetes/kubernetes/blob/master/pkg/OWNERS and see what people complain about not being able to do :)
Something else (what)? I totally agree with what @philips said above. There are many pains in reviewing and maintaining some packages that only people doing it without the access will know.
I've asked too. My answer to the list:
area/*
and team/*
mostlyThe project feature bit is interesting because it gives visibility to the community, which is great, but makes it impossible for any person without write-access to collaborate on the project with equal footing... and making the bot capable of doing github-project tasks would be pretty complicated I'd expect! Unless github adds better granularity for github-project permissions, it might be best to just give up on it and choose some better tracking system that will allow good enough permissions.
Thanks everyone for the feedback! As someone mentioned earlier, github's permissions are not perfect, and we're working to grant access to a lot of the functionality requested above. Specifically, we're trying to:
/lgtm
which will create an lgtm label/dibs
or /assign
- command hasn't been decided yet)Also, note that the contribX working group meets every other Weds at 9:30am, and we discuss things of this nature, so if you have additional ideas/feedback, please join us!
@grodrigues3 That sounds like great progress!
But, the feedback from fabionofranz, anguslees, and myself is that we want to make kubernetes/kubernetes healthy by ensuring people are empowered to groom our issues. What is the plan for enabling folks to help close and triage bugs? The 4,585 bugs open are a lost cause until we empower more people.
Hi @grodrigues3 ,
It sounds like an advertisement for the contribx features of github bot. If so, I'm totally supportive of that too.
I actually couldn't agree more with what @philips said above. As the rule of thumb, we are facing real issues and working hard on it. We need to have access to the code we write, maintain, and review. This will help us get the work done more efficiently and better. In return, it helps make the k8s community and project better.
Secondly, I am a supporter of the idea of more organized hierarchical ACL that contribx group are working on. I have help contributed three features too. But it still has some way to go to be mature and used by everyone. What about the period before that? If the new contributors/maintainers are waiting while the rest have access, it's not gonna help with the situation. Because 1. people get used to the github features to do the same thing and it might take more efforts and time for contribx to compete with Github (remember how we have discussed about "approval" and finally github released a feature like that?); 2. even worse, probably no one is gonna use the features and contribx will be in oblivion. So in conclusion, I think the right way to go to realize contribx plan is to actually remove all existing owners' access and start using the contribx features.
However, it will take some time and patience to educate community and get people understand how important and great the organized ACL is, just like Linux. Before that, what's the temporary solution to authorize new contributor/maintainer for a subsystem? I think that's what we are asking basically. But I think it's totally fine to remove write accesses from all people eventually.
@philips The 4585 open issues are a lost cause unless we can develop a scalable system for routing them to subteams, SIGs, or something.
Changes to assignments, labels, milestones on individual issues all seem fairly reasonable. Changes to labels on PRs is trickier, since they are used by the bot. Changes to assignments on PRs affects who can /lgtm, currently. Changes to milestones on PRs should be fine.
Is anyone familiar with "Integrations"?
Anyway, current permission levels are: https://help.github.com/articles/repository-permission-levels-for-an-organization/
We also use protected branches to protect master and all release branches: https://help.github.com/articles/about-protected-branches/
Another approach we could take is looking at what capabilities we wouldn't want 500-1000 contributors to have. For example:
Hmm. Apparently people with read access can edit the wiki now. We should probably move the wiki out of the kubernetes repo, anyway.
@philips @hongchaodeng If you're suggesting that we add more people to kubernetes-maintainers now, then we need to develop an official policy for who can be included.
Note: We should consider changing from labels to PR statuses to control PR mergeability: https://developer.github.com/v3/repos/statuses/
This would apply to lgtm, approve, do-not-merge, CLA labels, release-note labels, perhaps cherrypick labels, probably others I'm forgetting. Not sure what to do about other labels that affect submit-queue behavior, like priorities and retest labels.
Statuses are properties of the commit, not of the PR, so that's not very widely applicable. They're also much less visible to humans than labels are.
LGTM would work, and you'd get the lgtm-cancel behavior after a push for free, but things like do-not-merge or release-note labels don't make sense to attach to a particular commit.
On Mon, Oct 31, 2016 at 4:56 PM, Brian Grant notifications@github.com wrote:
Note: We should consider changing from labels to PR statuses to control PR mergeability: https://developer.github.com/v3/repos/statuses/
This would apply to lgtm, approve, do-not-merge, CLA labels, release-note labels, perhaps cherrypick labels, probably others I'm forgetting. Not sure what to do about other labels that affect submit-queue behavior, like priorities and retest labels.
— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/1908#issuecomment-257454456, or mute the thread https://github.com/notifications/unsubscribe-auth/AAM7nIXOAtDgTD1lpKLwGHl52VirPv-yks5q5oA5gaJpZM4KdZgN .
Is anyone familiar with "Integrations"?
Yes, those will help quite a bit. Right now it's early-access and not stable, so I'm holding off on switching our systems over.
It makes some sense to use statuses for LGTM and approval, but I think we can make labels work. The downside is that it's annoying to write /label kind/velocity-improvement
. Much easier to click the labels button and search for something like "vel" and then click the appropriate label.
cc @sarahnovotny
Thanks for putting the effort into solving this. I think the bot thing will definitely help and will wait on that. Just wanted to help make things faster, not more complicated.
@idvoretskyi
Questions:
Set some other labels on PRs - assign to SIGs, label with the actual feature status
What do you mean by "actual feature status"?
I'd like to keep the rules about what should and shouldn't be done to PRs to be as simple as possible.
Edit wiki
What parts of the wiki in the kubernetes repo? It's likely that whatever content you need to modify should be moved elsewhere.
@bgrant0607
What do you mean by "actual feature status"?
Other words: I'd like to make sure that kubernetes/features repo items are in sync with kubernetes/kubernetes and vise versa. So, the issues/PRs in kubernetes/kubernetes have to be labeled with regards to kubernetes/features.
What parts of the wiki in the kubernetes repo? It's likely that whatever content you need to modify should be moved elsewhere.
Yes, I've double-checked the wiki content, most if the wiki items in my field of interest are targeting kubernetes/features and kubernetes/contrib mostly.
[WIP]have the release note added automatically based on the PR template (what the author writes in the template
@grodrigues3 any news regarding this? I've been using /lgtm
a lot and it's great, but I have to say it's pretty much useless without /release-note-*
or automatically setting it based on the PR template like you said. :(
Example: https://github.com/kubernetes/kubernetes/pull/37270
/release-note and /release-note-none will set labels (similar to /lgtm), if the template-based matching doesn't work for whatever reason. kubernetes/test-infra#1332 @fabianofranz
/release-note and /release-note-none will set labels (similar to /lgtm), if the template-based matching doesn't work for whatever reason.
@rmmh that's awesome news, thanks a lot!
@rmmh I don't like the idea of using bot commands to set release-note labels. The intent was that filling out the issue template should cause the appropriate labels to be set. Circumventing that seems like a bad idea. If the template needs to be simplified so that people don't just delete it, we should do that. Otherwise, contributors will continue to not think about release notes and we'll always be left scrambling trying to figure out what went into a release. Or, if we just need a totally different mechanism, based on features issues or something else, we should do that and eliminate the release-note labels on implementation PRs.
cc @david-mcmahon @spiffxp
@rmmh I don't like the idea of using bot commands to set release-note labels. The intent was that filling out the issue template should cause the appropriate labels to be set. Circumventing that seems like a bad idea. If the template needs to be simplified so that people don't just delete it, we should do that. Otherwise, contributors will continue to not think about release notes and we'll always be left scrambling trying to figure out what went into a release. Or, if we just need a totally different mechanism, based on features issues or something else, we should do that and eliminate the release-note labels on implementation PRs.
Agreed, but until that is in place and working well, the /release-note
commands should make life easier. It was something I was able to implement in an hour or so, so I just did it :)
@bgrant0607 of the last 1000 PRs merged (since Oct 29), only 10% have followed the format the munger recognizes for automatic release note labeling (**Release note**:
). Many contributors are electing to not use the template.
We should support the 90% workflow while working to improve it-- maybe the template would be more used if people knew about its benefits.
Part of the problem is that the template mixes template AND instructions. It's "too much effort" to delete part of it and not all of it. IMO (and I helped write the template, so ...)
On Fri, Dec 9, 2016 at 2:30 PM, Ryan Hitchman notifications@github.com wrote:
@bgrant0607 https://github.com/bgrant0607 of the last 1000 PRs merged (since Oct 29), only 10% have followed the format the munger recognizes for automatic release note labeling (Release note:). Many contributors are electing to not use the template.
We should support the 90% workflow while working to improve it-- maybe the template would be more used if people knew about its benefits.
— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/1908#issuecomment-266141066, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVEX0HtNLnp00abFWSShCSt-MklNbks5rGdaAgaJpZM4KdZgN .
@fejta announced some commands that address some of these issues: https://groups.google.com/forum/#!topic/kubernetes-wg-contribex/t6aceRk03Ag
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.
Prevent issues from auto-closing with an /lifecycle frozen
comment.
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
@bgrant0607 Any concrete advantages for keeping this issue open or can it be closed by now that sig-contribex is continuously working on these things? Any concrete action items here not covered within the SIG's scope?
/close I swept through this and have noted the remaining unimplemented functionality in kubernetes/kubernetes#57667
@tmrts @pires @fabianofranz @pipejakob @idvoretskyi @bdbauer @feiskyer @chrislovecnm @wonderfly @hongchaodeng
You have requested to be added to kubernetes-maintainers in the past 9 months.
Why?
What exactly were you trying to accomplish such that you thought write access to the kubernetes repo would make it possible or help?
Once I have a reasonable list of items I'll send a questionnaire to contributors more broadly to help prioritize work in contributor experience.
cc @kubernetes/contributor-experience @grodrigues3