Community: help wanted label to target current and/or experienced contributors

[parispittman]

I'll go ahead and open up this bike shed/pedantic adventure.

Both good-first-issue and help-wanted label guidelines are targeting new contributors with varying levels of support/mentoring involved.
I would love to have a label/bat signal to current contributors (or those with targeted expertise in that part of the codebase) that means I can't give out too much support but it's very much open to work on. What should this be?

https://github.com/kubernetes/community/blob/master/contributors/devel/help-wanted.md

[cblecker]

Wouldn't that just be "anything that is not those things"?
e.g. is:open is:issue -label:"good first issue" -label:"help wanted" no:assignee

[parispittman]

@cblecker that makes for one heck of a statement when I'm out and about ha. "just look at help wanted in x repo" is kinda what I'm going for here. I think a lot of our contributors use help-wanted in this way, too.

i guess i just like the idea of help wanted label without needing a ton of the criteria of the guideline?

[astrieanna]

I think your link is already redirected: https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md

[BenTheElder]

Wouldn't that just be "anything that is not those things"?

Not exactly. A trivial counter-example if the issue is already assigned and lifecycle/active.

There's a subtle difference between "this issue is tracked and active contributors are on it" and "this issue is tracked but won't happen soon without help, and no, it's not first time contributor friendly".

You could argue for priority/backlog on the issue but there's also a difference between an issue being important and an issue having people working on it.

I might think cleaning up the crazy build glue in Kubernetes is much higher priority than priority/backlog but not know anyone with enough time to tackle it right now...

[astrieanna]

@parispittman @BenTheElder In a world where there was a label for the category you're describing, what would the criteria be to apply that label? And who would be the target audience to pick those issues up?

[nikhita]

this issue is tracked but won't happen soon without help, and no, it's not first time contributor friendly

Wdyt about is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee?

Personally, I see this as "this issue is important to us in the short term, but we've got no one working on it right now and anyone is welcome to take it up. it doesn't have good first issue or help wanted labels so it's not really beginner friendly either".

[BenTheElder]

Wdyt about is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee

I think if I people need to use a query they won't find it. "Help wanted" stands out. It says we want help :-)

The target audience is twofold:

• signaling, IE acknowledging that nobody is currently looking to work on it for users that want to see the issue fixed but don't intend to contribute (🤷‍♂️ lots of those for some projects)

• for existing contributors with some experience but perhaps not exactly maintainers to signal that the project maintainers would like help in particular with certain issues

The latter point is also a big problem for me. With only help wanted / good first issue, somewhat experienced contributors tend to take on the good first issues before actual new contributors ever see it. I'd love to say "look for this label instead please" after I've gotten so many PRs from someone and save the starter issues for onboarding new people :-)

[nikhita]

Follow up questions :)

I think if I people need to use a query they won't find it.

Would this mean to add help-wanted-from-experienced-folks (or something of that sort :stuck_out_tongue: ) to all issues that match is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee?

signaling, IE acknowledging that nobody is currently looking to work on it for users that want to see the issue fixed but don't intend to contribute

Why doesn't is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee _acknowledge_ that nobody is working on it but we want it fixed? :)

[BenTheElder]

Somewhat alternatively something like needs-discussion would be helpful ... there are a lot of tracked issues without clear solutions that really aren't set up for many people to jump into easily yet, like: https://github.com/kubernetes/community/issues/3753

Would this mean to add help-wanted-from-experienced-folks (or something of that sort 😛 ) to all issues that match is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee?

I think? @parispittman to confirm for her use cases.

I was using "help wanted" for issues like this in kind (as opposed to "good first issue). FWIW this actually worked and some more confident individuals leaped in to tackle them as opposed to other issues that are a lot further from implementable..

Why doesn't is:open is:issue -label:"good first issue" -label:"help wanted" label:priority/important-soon no:assignee acknowledge that nobody is working on it but we want it fixed? :)

because many (most?) of these users aren't even community members at all, they don't know what all of our labels etc. are, but they can read a bright yellow "help wanted" label on the page and guess from there that we're looking for help to get anything done...

[BenTheElder]

I would contend that _most_ individuals interacting with our issue trackers are never going to read our labeling guidelines, so having labels that intuitively mean various things is pretty important.

It's rather unfortunate that GitHub has decided that help wanted, good first issue and kind/documentation are automatically listed under https://github.com/$org/$repo/contribute (a page I can't actually seem to surface in the rest of the UI...). This causes eg https://github.com/kubernetes/community/issues/2833 to show up in https://github.com/kubernetes/community/contribute which doesn't really seem right..

Also FWIW our own current re-definition of "good first issue" to be different from "help wanted" doesn't really gel with pages like https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels

[astrieanna]

The goal is to highlight issues in a more curated and obvious way than a search filter (and maybe add needs discussion to help with filtering) so that people who have already landed a couple PRs can pick up harder but not maintainer-only work.

It sounds like the desire is for a looser help wanted so that more/harder issues can be added. The current criteria for help wanted are:

• Low Barrier to Entry
  It should be tractable for new contributors. Documentation on how that type of change should be made should already exist.
• Clear Task
  The task is agreed upon and does not require further discussions in the community. Call out if that area of code is untested and requires new fixtures.
  API / CLI behavior is decided and included in the OP issue, for example: "The new command syntax is svcat unbind NAME [--orphan] [--timeout 5m]", with expected validations called out.
• Goldilocks priority
  Not too high that a core contributor should do it, but not too low that it isn't useful enough for a core contributor to spend time to review it, answer questions, help get it into a release, etc.
• Up-To-Date
  Often these issues become obsolete and have already been done, are no longer desired, no longer make sense, have changed priority or difficulty, etc.

I'm assuming that 'Low Barrier to Entry' should be dropped, since the idea is that the contributor is has some idea how to make changes. The other criteria still seem reasonable for this use case to me. If the task isn't clear, then your drop-in contributor can't pick-up the work (because it's too much work to even get started). If it's too low priority or not something you actually want done, then you don't want to highlight it for them to work on anyway.

@BenTheElder Is this an accurate summary?

[nikopen]

This is relevant to the Triage KEP I am preparing.

The KEP includes the proposal of a new label - lifecycle/ready,
that indicates issues that are prioritized but not currently worked on by anyone.

Issues with this label applied are obvious candidates for the scenario discussed here.

In addition I propose:

• good-first-issue to target _both_ "no barrier" _and_ "low barrier" of entry

• help-wanted to target _anyone_. If there's no good-first-issue in, then it's something more advanced.

• lifecycle/ready will be a relevant indicator of issues that are triaged and ready to be worked on.

• lifecycle/active will be indicating issues actively worked on by someone.

How does this sound?

[nikopen]

An addition to give more clarity:

• Rename good-first-issue to low-hanging-fruit so it's not necessarily a first issue :)

[fejta-bot]

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.

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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.