Community: Installing Issue-Label Bot

[hamelsmu]

Hello Maintainers, we (@inc0 and myself at GitHub) have been working closely with maintainers to build machine learning products that can help maintainers with GitHub apps.

We would like to propose installing the GitHub App Issue Label Bot. This app is 100% open source and was developed with the community. This app is already installed on other open source projects such as:

• Kubelfow: example 1, example 2
• Apache Superset: example 1, example 2

This app can be installed/uninstalled anytime via the GitHub marketplace with a push of a button so it is really easy to manage if you do not like it.

We would like to see if this app could be installed on the following repos:

• kubernetees/community
• kubernetees/kubernetees
• kubernetees/enhancements
• kubernetees/contributor-experience

Features:

• The app will detect if the issue is related to a question, bug or feature request. You can alias these labels to suit your repo with a yaml file like this.
• The app gathers feedback and will improve over time.
• The app is built using Kubernetes ❤️ and Kubeflow, which is an awesome Kubernetes project that provides machine learning infrastructure. This app is currently hosted on GCP.
• It is 100% open source MIT license and we are accepting PRs.
• FREE

Our Goals

• We want to work with K8 maintainers to add new features to this app and iterate further. For example, to add more labels or to do other customized things we are not thinking about. We take this opportunity to collaborate very seriously and would love to add new features or create a new type of app altogether.
• Engage with the K8 maintainer community in open source for these tools so we have a path to adding additional tools.
• Help maintainers in general, and help the K8 community ❤️

Please let me know your thoughts!

cc: @parispittman @jlewi @mrbobbytables @spiffxp @inc0 @becca @nikhita

[spiffxp]

/assign

[spiffxp]

https://github.com/organizations/kubernetes/settings/installations/951764 - the app is currently installed but not enabled for any repos, pending signoff from sig-contribex

[spiffxp]

apparently I accidentally had this enabled with its default labels for kubernetes/community for a bit, the aforelinked installation has been deleted

[spiffxp]

@hamelsmu sounds like we'd like you to demo this functionality at an upcoming sig-contribex meeting https://github.com/kubernetes/community/pull/3707#issuecomment-492074570

what's your availability like?

[hamelsmu]

@spiffxp sure I’m pretty open and can make myself available anytime. Let me know what works for you!

[spiffxp]

@hamelsmu today's meeting was short for kubecon planning, next week most of us will be at kubecon, I would e-mail kubernetes-sig-contribex@ to ask when the next meeting is and get on the agenda

[nikopen]

@hamelsmu this looks great.

Have a quick read through https://github.com/kubernetes/community/issues/3456 if you will, currently draft proposals soon to be more concrete.

It will be interesting to have functionalities of automatically applying labels through project boards - ticket moved to column X gets label Y, and vice versa (ticket having labels Y and Z moving to project board U column Y) etc. Could the bot help with that?

[hamelsmu]

@nikopen that sounds like a good use case for another bot and might be simple to implement (no machine learning required).

Some follow up/questions:

• Need someone to sponsor the hosting of this bot, do you have any ideas? (I can try to find a home if nothing comes to mind).
• Should the issues be labeled as the same name of the column in the project board?

[nikopen]

CNCF infra is still incubating, not sure if it's able to host it, @spiffxp @dims maybe you know better? Most things are still hosted in Google infra like Prow etc.

Columns will likely have standard kanban names like "in progress" , corresponding labels will probably be a bit different like "lifecycle/active" and so on. If it's more practical to have the same column names and labels it's possible to do so

[nikhita]

Closing since it was discussed in the contribex meeting to not move forward with this for now. Let's reopen if we revisit this in the future.

@hamelsmu Thanks for showing up to the meeting and giving the demo! Loved the collaboration :)

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

Closing since it was discussed in the contribex meeting to not move forward with this for now. Let's reopen if we revisit this in the future.

@hamelsmu Thanks for showing up to the meeting and giving the demo! Loved the collaboration :)

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

[nikopen]

@nikhita What are the reasons it was decided to not move forward?
I can hardly see any negative points.

[nikhita]

@nikopen mainly that issue templates help in categorizing issues into bug, feature, etc already.

[nikopen]

@nikhita obviously that's an existing layer of categorization but there's a big number of new issues that are wrongly categorized, and that's the intention and playfield of this bot.

What is the actual counterargument?

[hamelsmu]

@nikopen no fear! I’m currently in the process of building a new version of the bot that will suit the k8 community much better. Might take me some time as I’m currently on parental leave so I’m working on it as time allows. I’m pretty optimistic about it. The new bot will hopefully will be able to offer a more fine grained ability to label k8 specific things like sig/ labels etc.

[cblecker]

@nikopen The bot currently only does three buckets of categorization: bug, feature, support request. We have issue templates to do this categorization now, and we actually want to use them so we can redirect/deter folks from submitting support requests period. Most outside users, if offered those three options, can categorize their request correctly.

We also just don't need more bot chatter on issues, especially if most issues will already be categorized.

As @hamelsmu mentioned, we did talk about some possible future enhancements to handle SIG labelling instead of bug/feature/support request. That would be extremely useful to us, as although outside users can pick up on if their issue is a bug vs a feature request, it's much more difficult for them to identify the correct SIG. We're going to revisit this at a later time.