search

kubernetes-retired / contrib

[EOL] This is a place for various components in the Kubernetes ecosystem that aren't part of the Kubernetes core.
Apache License 2.0
2.46k stars 1.68k forks source link

Prioritize contributor inconveniences #1908

Closed bgrant0607 closed 6 years ago

bgrant0607 commented 7 years ago

@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

wonderfly commented 7 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.

pires commented 7 years ago

Mostly, be able to set:

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 👍

bgrant0607 commented 7 years ago

@pires If most of your work is on kubeadm, your problem would be solved by moving kubeadm to its own repo. :-)

fabianofranz commented 7 years ago

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! ;)

bgrant0607 commented 7 years ago

@fabianofranz LGTM can be achieved by /lgtm now, FYI, if the PR is assigned to you.

fabianofranz commented 7 years ago

LGTM can be achieved by /lgtm now, FYI, if the PR is assigned to you.

Didn't know that, thanks!

fabianofranz commented 7 years ago
pires commented 7 years ago

@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.

feiskyer commented 7 years ago

For me, mostly be able to

tmrts commented 7 years ago

I used my write access for:

Without write-access, these inconveniences can be alleviated by:

  1. GitHub allowing finer-grained settings (Label write access, Assign write access as opposed to blanket write access)
  2. Splitting the monorepository and distributing write access accordingly (e.g. sig-node gets write access for the node repository)
  3. Extending the tooling (i.e. allowing /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.

chrislovecnm commented 7 years ago

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.

pipejakob commented 7 years ago

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 .

anguslees commented 7 years ago
idvoretskyi commented 7 years ago

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.

timothysc commented 7 years ago

+1000 to issue hygiene.

chrislovecnm commented 7 years ago

@bgrant0607 thanks for addressing this! How will the bots work with this?? We need k8s-bot in kops.

spxtr commented 7 years ago

@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.

philips commented 7 years ago

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)?

philips commented 7 years ago

@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 :)

hongchaodeng commented 7 years ago

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.

euank commented 7 years ago

I've asked too. My answer to the list:

The 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.

grodrigues3 commented 7 years ago

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:

  1. [WIP]have the release note added automatically based on the PR template (what the author writes in the template wThe contribx wg
  2. [DONE] allow reviewers (must be assigned to the PR) to comment /lgtm which will create an lgtm label
  3. [WIP]Self assigning PRs to review or issues to work on (/dibs or /assign - command hasn't been decided yet)
  4. [WIP] Unassigning oneself from PRs that have been assigned to you to review (if you don't have the bandwidth)
  5. [near future] assigning someone else to a PR/issue

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!

philips commented 7 years ago

@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.

hongchaodeng commented 7 years ago

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.

bgrant0607 commented 7 years ago

@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.

bgrant0607 commented 7 years ago

@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.

bgrant0607 commented 7 years ago

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.

rmmh commented 7 years ago

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 .

spxtr commented 7 years ago

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.

bgrant0607 commented 7 years ago

cc @sarahnovotny

bgrant0607 commented 7 years ago

Please see: https://groups.google.com/forum/#!topic/kubernetes-dev/owb9kYKmicU https://github.com/kubernetes/community/tree/master/project-managers

pires commented 7 years ago

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.

bgrant0607 commented 7 years ago

@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.

idvoretskyi commented 7 years ago

@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.

fabianofranz commented 7 years ago

[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

rmmh commented 7 years ago

/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

fabianofranz commented 7 years ago

/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!

bgrant0607 commented 7 years ago

@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

spxtr commented 7 years ago

@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 :)

rmmh commented 7 years ago

@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.

thockin commented 7 years ago

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 .

bgrant0607 commented 7 years ago

@fejta announced some commands that address some of these issues: https://groups.google.com/forum/#!topic/kubernetes-wg-contribex/t6aceRk03Ag

fejta-bot commented 6 years ago

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

luxas commented 6 years ago

@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?

spiffxp commented 6 years ago

/close I swept through this and have noted the remaining unimplemented functionality in kubernetes/kubernetes#57667