More PR automation

[bgrant0607]

• Explicitly notify the PR author if the PR is stuck: tests failed, needs rebase, needs release note, etc. The notifications that don't mention anyone won't rise above github notification noise.
• Explicitly notify the PR assignee if the PR needs them to do something: ok to test, ok-to-merge, e2e--not-required, reapply lgtm label after rebase, release note label, etc.
• Ping the PR due to lack of inactivity, notifying either the PR author or the assignee, depending on who last touched the PR (keep track of whose court it's in)
• Create a way to postpone the next ping for a fixed amount of time (day, week, month, next release cycle)
• Reassign PRs whose assignees never responded
• Reassign PRs that need approval from someone other than the current assignee (part of OWNERS proposal)

@fejta @philips @eparis

[philips]

@bgrant0607 for someone wanting to start working on this is it expected to be an extension of the existing k8s-bot? And if so where does that code live?

cc @mike-saparov

[bgrant0607]

@philips Yes, I'd extend the existing bot.

Existing code is here:
https://github.com/kubernetes/contrib/tree/master/mungegithub

For example, the existing auto-assigner:
https://github.com/kubernetes/contrib/blob/master/mungegithub/mungers/blunderbuss.go

[bgrant0607]

Other ideas:

• Dashboard with numbers of PRs stuck in each state: needs rebase, needs review, comments to address, waiting in queue, etc.
• Dashboard with histograms of number of rebases per PR, PR latency (by PR size)

cc @apelisse @goltermann

[bgrant0607]

If a commenter didn't notify the other party, we should explicitly notify them, without waiting for the full inactivity threshold.

If the author performed some action that doesn't generate a notification (e.g., pushed changes), we should generate the notification.

Tests passing should notify the reviewer.

[bgrant0607]

See also #481

[bgrant0607]

We should check out https://github.com/facebook/mention-bot (#1250).

[bgrant0607]

Looks like I also filed this here: kubernetes/kubernetes#24844

[bgrant0607]

@apelisse This is the task I was referring to.

cc @matchstick

[bgrant0607]

Example: kubernetes/kubernetes#28936

[bgrant0607]

The Google CLA bot doesn't explicitly notify the author. Example:
kubernetes/kubernetes#29452

Our bot will likely take over notification and labeling when we switch to the CNCF CLA (kubernetes/kubernetes#27796).

[bgrant0607]

We need notifications for:

• PR assignment
• Commit push
• Build / unit test failure

[bgrant0607]

PR workflow proposal:
https://docs.google.com/document/d/194MGgJHlm4ovXtvzvkjzzBZG_v47d95nsjuuaUe1Log/edit?ts=57929ed1#

[bgrant0607]

Github added more signals to notification emails. I'll adjust my filters to take advantage of these and will report whether it helped. We should add a link to this in our PR workflow documentation:
https://help.github.com/articles/about-notification-emails/#the-cc-address

[bgrant0607]

We could autodetect messages like "this should be closed".
Example: kubernetes/kubernetes#28817

[apelisse]

Somewhat related but @fejta and I agreed that it would be nice to have a close-stale-flake-issues munger.

[bgrant0607]

"ok to test" messages don't notify anyone.
Example: kubernetes/kubernetes#30208

[bgrant0607]

As discussed, we should change all bot instructions to clear commands, like:

/TEST
/RETEST
/LGTM
/APPROVE
/PTAL

Plain english can be misinterpreted ("lgtm if you do X"), long phrases ("@k8s-bot test this issue: #IGNORE") are hard to remember, and sometimes requiring bot notification and sometimes not is confusing.

[janetkuo]

Now if you LGTM in reviewable it prints this:

Can bot also respond to this?

[bgrant0607]

I'm finding that many reviewers are not aware of /lgtm. I think that when the bot assigns a reviewer, it should post tips for reviewing, including common commands, info about Reviewable, link to more info, etc.

[fejta-bot]

Issues go stale after 30d 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

[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
/remove-lifecycle stale