This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/sig Contributor Experience

@jsoref: The label(s) sig/contributor, sig/experience cannot be applied, because the repository doesn't have them.

Please note that the bot @k8s-ci-robot said /sig <group-name> and https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups clearly says that the Name is Contributor Experience:

/sig contributor-experience

@k8s-ci-robot 's help should say /sig <group-label> not /sig <group-name>

/kind feature

The existing template provides some help; this is a request to make it even more helpful. I presume we could repeat that for lots of other automatically managed Git repositories.
/remove-kind bug

Thank you for the suggestion.

@k8s-ci-robot 's help should say /sig <group-label> not /sig <group-name>

Not quite. /sig sig/contributor-experience would also be wrong. However, if we find a volunteer to do it, we could accept the alternatives when they are unambiguous and provide better advice when they are not.

The SIG that looks after this automation is SIG Testing.
/sig testing

/retitle kubernetes/client-go:.github/PULL_REQUEST_TEMPLATE.md is unhelpful plus suggestion about SIG labelling

@sftim: wait, the Column Title clearly says Label, it sounds like you're saying that's wrong and it should in fact say Label Suffix and then the help could be changed to /sig <sig-label-suffix>?

Note: I'm willing to do this work if people can point to the places and offer to support me doing the work.

This seems like at least a dozen different issues filed as one enormous issue which makes it difficult to actionably fix them.

I appreciate that these things are painful and writing them up to highlight them is potentially useful but as only one large issue they're difficult to follow up on, remember that many responding to these are also likely seeing an influx of issues.

SIG Testing runs and implements the automation, but currently Contributor Experience maintains that all contributor facing changes to the behavior must be approved by them, including changes to the help text ...

The robot currently grew out in https://github.com/kubernetes/test-infra (though we're hopefully about to break it out into a distinct kubernetes-sigs/prow repo ...). The prow/ directory contains most of the relevant bits, along with config/ which contains the config for our specific instance (some of the comments are configurable templates).

I can't offer much bandwidth myself at the moment, there's too many things to take care of. Usability papercuts pile up but the thing is no one is paying people to work on the robots much anymore and volunteers are pretty busy trying to keep things running (e.g. kubernetes/k8s.io#6165).

Some of the maze of links is because there's a generic template project with stub files, and client-go just has the stub files. They might accept adding more details, IMHO it would be good for the staging repos to have their own more-specific CONTRIBUTING.md contents that contain the details on how to contribute to these. The template repo stub files explicitly suggest that subprojects add their own details but that hasn't happened here yet.

Also comments like:

Note that YouTube is misspelled on this page as well as on the previous page -- apparently respect for other brands isn't a community value (this does appear to be the case, remember if you read https://github.com/kubernetes/community/blob/master/values.md#community-over-product-or-company that the "value" is "Community over product or company")

Are a bit over the top. Mistakes happen, missing the case on this isn't any contributor intentionally disrespecting anyone or any company.

As for the values reference: The point of "Community over product or company" is that we strive to make decisions and take actions on the basis of what's best the project at large rather than favoring a particular company including our own employers, and the project on the whole aims for vendor-neutrality.

It's impolite not to assume best intentions.
I understand you were frustrated when writing this issue, but let's remember that our contributors and maintainers are doing their best.

These docs could use more contributors cleaning them up.

Get annoyed at some of the prerequisites because they aren't really relevant -- and they also aren't even logical. A bot is not going to check to see if you have a GitHub account because you can't get to the bot until you have one.

The contributor guide is general to anyone looking to contribute, the bot links to this rather than duplicating most of this content somewhere else.

We should probably start linking to https://www.kubernetes.dev/docs/guide/ instead of github. I'm not sure if Contributor Experience considers this replacement ready though, there was a period where there were two copies of the contributing docs with one intended for this site and one the legacy content ...

There's a link to Kubernetes code of conduct (which is not written with the proper case -- so you don't know if it's the same as other documents or not, it is, in fact, the whole text is silly as it's actually the CNCF CoC -- I believe that this issue falls well within that guidance).

GitHub looks for a code-of-conduct.md and marks if a repo has one or not.
The current policy is to defer to CNCF's Code of Conduct.

Sorry. For pretty much every item I enumerated, I'm willing to do the work to improve the experience (as long as people are willing to help me deal with whatever hurdles I might encounter, whether that's policy, bots, quirks, or just a lack of an obvious path forward). I happen to have a tool that works on spelling things (including branding items like YouTube) and thus that's actually the easiest item for me to fix.

But yes, this is absolutely death by a thousand paper-cuts. I understand you're low on volunteers, but if the hurdle to get through the door is sufficiently high, you won't get many more and you'll continue to bleed or hemorrhage as applicable.

Anyway, pick 5 of the paper-cuts identified above that you (the project, not the person) are willing to let me improve, suggest a general direction that would be acceptable to the project and I'll see what I can do.

One approach I've found that works well for things like this is for me to "sit" (virtually or physically) with someone and go over a section asking questions, clarifying, and fixing things. It's usually possible to get some portion fixed in 15 minutes, although longer runs can take half an hour or an hour, but conveniently whatever is addressed is a clear improvement and it's an interruptible/resumable process as it's unlikely that anyone else will be changing the process or the documentation between interrupting and resuming.

I haven't even gotten to the paper-cuts involved in actually trying to make a contribution for this project.
The PR template includes a link to:

• https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#is-the-feature-wanted-file-a-kubernetes-enhancement-proposal "It's better to get confirmation beforehand." -- well, this comment is me asking before I spend my time on this.

• The text includes the word prefactoring a bunch of times. I have no idea what it is. Google shows something from after I graduated university and was already in the industry for a while, and the wikipedia article doesn't actually seem to fit the context leaving me with a 🤷‍♂️.

• https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#dont-open-pull-requests-that-span-the-whole-repository

• I'm glad it tells me not to create a PR based on running a spell-checker across the whole repository.

  You can look at the OWNERS files in a directory (or its parent directory) to see who owns that code, and then group the changes together accordingly (e.g., with one PR touching files in cmd/kube-proxy and pkg/util/iptables, which are owned by SIG Network, and another PR touching files in pkg/kubelet and pkg/controller/nodelifecycle, which are owned by SIG Node.)

  Sadly, that . at the end is on the wrong side of the line. It seems like the first thing I'd want to work on is just the PR template itself.

• Read up on GoDoc - follow those general rules for comments.

  • for my future reference, it appears to be Godoc ...
  • note that the blog has a note about an updated page and I can't tell if the blog or the updated thing is really what one should be reading...

• https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#trivial-edits

  If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking the formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file.

  So, it seems that at least outlining the flaws for a section as opposed to trying to do a single item is recommended by this file...

  Note: I have no intention of boiling any oceans. I also have lots of experience splitting work into reviewable chunks.

  A generic explanation of how labels are used in pull requests can be found here.

  • here links are generally considered harmful (the same critique would apply to "See the current list of tests at this link")
  • (the owners.md file could also use love, but in the spirit of not boiling oceans, let's focus on fixing the PR template first...)

  The behavior of Prow is configurable across projects. You should be aware of the following configurable behaviors.

  • That . should really be a : (there was a colon used a few lines up...)

  If the failure is a flake, anyone can comment /retest if the pull request is trusted

  • This item is repeated from somewhere else in the flow -- by the time I'm here, I've lost all the useful context, and I don't think it's possible for the PR not to be trusted, which to me makes it seem like at least if the pull request is trusted is superfluous/counterproductive.

• https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#more-about-ok-to-test

  The ok-to-test label is applied by org members to PRs from external contributors, it signals that the PR can be tested.

  • the earlier ok-to-test text used the word trusted, this section doesn't, that's unfortunate because it means that the two sections aren't well linked.

  An ok-to-test label may reduce the workload and smoothens the contributors experience as they can know if there is any failing test. If there is, you can fix the test and they don't have to wait for a long time to get a review from maintainer/assignee.

  • I can't tell who you is here -- is it the reviewer or the contributor?

  PRs with tag do-not-merge/hold or needs-rebase should make the appropriate changes before the PR can be labelled ok-to-test.

  • voice got worse here, at least before there was a person, not the PR itself that needs to make changes? 😵 -- it's probably as simple as changing make to have and before the PR can be labelled ok-to-test to made before a reviewer (?) labels the PR with/as ok-to-test

  PRs created by mistake without to meaningful change of code should not be labelled ok-to-test and closed.

  The not + and here doesn't actually do what the author meant -- and closed should probably be changed to but be closed instead.

None of the staging-derived repos actually take PRs (the doc says "Please send pull requests against the client packages in the Kubernetes main repository. Changes in the staging area will be published to this repository every day.")

Yeah, many of these issues suck, I agree, but really you should not be able to open a PR against client-go at all, right? Can we just turn that off and emphasize the "PRs go to k/k/staging/k8s.io/client-go" instead?

@kubernetes/owners

Yeah, many of these issues suck, I agree, but really you should not be able to open a PR against client-go at all, right? Can we just turn that off and emphasize the "PRs go to k/k/staging/k8s.io/client-go" instead?

GitHub allows disabling issues for a repo but not pull requests.

We could add another bot behavior to auto-close PRs to these. Not great.

Fwiw, GitHub itself has the ability to block PRs:

Try loading: github/gh-actions-importer@main...add-tests-for-executable

An owner of this repository has limited the ability to open a pull request to users that have contributed to this repository in the past.

See /settings/interaction_limits

You'd need to renew it every 6 months (I'd suggest renewing it every 5 months).

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale