Repurpose fejta-bot + k8s-ci-robot to ping-bot

[abitrolly]

What should be cleaned up or changed:

The lifecycle messages for non-solved issues are getting annoying. The message below has erupted from this thread kubernetes/kubernetes#54923 (comment)

I don't get the point of this bot.

The bot will keep trying to close this issue, but I suspect as soon as it succeeds another Issue will take its place: There is clearly an Interest in this issue, so I'll keep "refreshing" this issue until someone tells me to stop.

I don't like doing this, since it just adds noise to this discussion, and will spam everyone observing or participating in this issue.
Is there a way around this eternal back-and-forth?

A solution to reduce the noise was to implement a ping instead of auto-close.

(btw totally agree, a "ping-bot" should be fine for the same use case and it wouldn't close it mistakenly)

An even better solution could be to have a process linked to ping-bot message. The process that allows to construct a heads-up or evaluate the importance and priority of the issue. Get updates on what's happening with it - is the issue forgotten, is somebody working on it, what is the next roadblock, is there some decomposition or decision needed to deal with the roadblock..

[immanuelfodor]

"totally agree" quote guy here, thanks for opening a separate issue for this 😃

[BenTheElder]

you can prevent cleanup and comments by commenting /lifecycle frozen. otherwise the intention (not mine) was to age out issues nobody is interacting with that have not explicitly been marked as "nobody is working on this but we need to keep it tracked"

workflow changes must go through @kubernetes/sig-contributor-experience
/sig contributor-experience

this should be migrated to github.com/kubernetes/community, if contributor experience agrees to changes, we can change the bot.

[BenTheElder]

thanks @mrbobbytables, xref: kubernetes/test-infra#20767
/sig contributor-experience

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[immanuelfodor]

A few weeks ago, I got the feedback that I should never use frozen on tickets, so I'm confused, and still support the ping alternative.

[immanuelfodor]

/remove-lifecycle stale

[abitrolly]

The ping-bot could also collect public stats about most missing issues, most annoying notifications and the longest waited features.

[BenTheElder]

A few weeks ago, I got the feedback that I should never use frozen on tickets, so I'm confused, and still support the ping alternative.

Sorry I'm just making it back through my own notifications (far too many...), can you share where you received this?
I know the enhancements repo had something like this, and I raised my concerns about that and we got this disabled there, but I'm not aware of this anywhere else and I don't agree, otherwise we would not have the ability to freeze issues.

@kubernetes/sig-contributor-experience PTAL

also regarding the bot naming: kubernetes/test-infra#12296

[immanuelfodor]

kubernetes/enhancements#361 (comment)

kubernetes/enhancements#362 (comment)

[BenTheElder]

Ok yeah, I strongly disagree with this and after discussion with SIG contributor experience in their slack about a week ago we got it disabled, you should not receive those comments again.

kubernetes/test-infra#22488 disabled them.

[BenTheElder]

I've just re-frozen those issues.

If there are any more in kubernetes/enhancements the same applies.

In particular there is no good reason for automation to pre-emptively close tracked enhancements that already have a merged KEP document but aren't GA / complete yet. I'm not sure I agree with the lifecycle system in general, but that stuck out as particularly pointless / unhelpful, so I was able to actually get movement on that part and it shouldn't happen anymore.

[spiffxp]

/close
The reasons fejta-bot is a separate account is because:

• it is unprivileged, as a demonstration of what any contributor could do with automation
• it avoids exhausting the GitHub API token limit used by k8s-ci-robot
• it was setup by someone named fejta

There is an issue to use k8s-triage-robot instead kubernetes/test-infra#12296

[k8s-ci-robot]

@spiffxp: Closing this issue.

In response to this:

/close
The reasons fejta-bot is a separate account is because:

• it is unprivileged, as a demonstration of what any contributor could do with automation
• it avoids exhausting the GitHub API token limit used by k8s-ci-robot
• it was setup by someone named fejta

There is an issue to use k8s-triage-robot instead kubernetes/test-infra#12296

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.

[BenTheElder]

and a more general issue regarding auto-closing (which is not the only thing the bot does) kubernetes/kubernetes#103151